The most insidious problem with these kinds of models is that they are trying to model <i>reality</i>.<p>Your example is modeling a <i>real dog</i> better than the sample you started with, but... what computer programs acts on a real, live dog, directly?  Computer programs pretty much <i>never</i> interact directly with external reality, only with other software -- interfaces to hardware and other software systems.  So software needs to be smart and clean about dealing with the actual interfaces. It&#x27;s important to understand how reality will interact with the interfaces, of course, but <i>relationships</i> there are often irrelevant or misleading to designing the software.<p>So all of these poor students, when actually charged with designing a program dealing with, say cashiers, store managers, purchases, reports, etc., start off &quot;well, cashiers and store managers are people, and actually both employees... I guess we need a company object in here&quot;, etc..  This almost always leads them into a mess, because they get lost in here before they even learn properly what the <i>goals</i> of their system are.  E.g., this program just needs to run on the store managers PC, pull data from a dir full of files from the POS, and generate reports (in which the cashier is just another column value).<p>If they started OO as &quot;modeling reality&quot;, just writing a program that does what&#x27;s needed feels like cheating (&quot;TODO: not really capturing the OO relationships here!  rework for v2&quot;) -- and that&#x27;s a bad thing.