Timeline for Breaking up classes and methods into smaller units
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 12, 2014 at 20:54 | comment | added | sea-rob | The counter-argument to that is the OO equivalent to "Spaghetti Code," which has been called "Ravioli Code". If you make your code really small, tightly encapsulated, and granular, then your application starts to look like a big plate of ravioli, where all the delicious little chucks are sort of laying around with no clear relation to each other. ...Then again, I read one OO expert's reply to that, "But isn't that what an OO application is supposed to look like?" | |
| Jun 12, 2014 at 20:51 | comment | added | sea-rob | Um, that felt long-winded. Basically, if your boundaries are well defined, and you have good separation of concerns, it makes it easier to reuse code, whether it's between systems, or between a v1 and a v2. So that argues for more granular code units. | |
| Jun 12, 2014 at 20:49 | comment | added | sea-rob |
If your code units are clear and have well-defined semantics (i.e. they mean something coherent), then odds are they won't change much in v2. A Sock is still a Sock. The trickiness in extending code is where different code units interact with each other. So if the logic for Sock leaks into the code for Drawer, then extending functionality will get tricky, because there's all this interaction logic that's scattered around. So, ideally, you'd want to boil things down into independent chunks that you don't have to change much.
|
|
| Jun 12, 2014 at 20:37 | vote | accept | micahhoover | ||
| Jun 12, 2014 at 20:35 | comment | added | micahhoover | Question about the v2 case you brought up: what if the new requirements involve reworking how all the internal modules relate to each other and a new dev is at the helm. Are very granular methods/classes advantageous or not in that situation? | |
| Jun 12, 2014 at 17:51 | comment | added | micahhoover | +1 for mentioning the way dealing with things on a higher level can help the code adapt in a faster, more understandable way. Your guidelines are objective, certainly, and perhaps a good rule of thumb. I completely agree with (3). (2) doesn't seem to work as well for cases where you have to do a lot of null checks (I consume a lot of XML, so that's my world :(). | |
| Jun 11, 2014 at 21:24 | history | edited | sea-rob | CC BY-SA 3.0 |
added 452 characters in body
|
| Jun 11, 2014 at 20:44 | history | answered | sea-rob | CC BY-SA 3.0 |