I’m a long time developer (I’m 49) but rather new to object oriented development. I’ve been reading about OO since Bertrand Meyer’s Eiffel, but have done really little OO programming.
The point is every book on OO design starts with an example of a boat, car or whatever common object we use very often, and they start adding attributes and methods, and explaining how they model the state of the object and what can be done with it.
So they usually go something like "the better the model the better it represents the object in the application and the better it all comes out".
So far so good, but, on the other hand, I’ve found several authors that give recipes such as “a class should fit in just a single page” (I would add “on what monitor size?" now that we try not to print code!).
Take for example a
PurchaseOrder class, that has a finite state machine controlling its behavior and a collection of
PurchaseOrderItem, one of the arguments here at work is that we should use a
PurchaseOrder simple class, with some methods (little more than a data class), and have a
PurchaseOrderFSM “expert class” that handles the finite state machine for the
I would say that falls in the “Feature Envy” or “Inappropriate Intimacy” classification of Jeff Atwood's Code Smells post on Coding Horror. I’d just call it common sense. If I can issue, approve or cancel my real purchase order, then the
PurchaseOrder class should have
Doesn’t that goes with the “maximize cohesion” and “minimize coupling” age old principles that I understand as cornerstones of OO?
Besides, doesn’t that helps toward the maintainability of the class?