|
The most insidious problem with these kinds of models is that they are trying to model reality. Your example is modeling a real dog better than the sample you started with, but... what computer programs acts on a real, live dog, directly? Computer programs pretty much never 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's important to understand how reality will interact with the interfaces, of course, but relationships there are often irrelevant or misleading to designing the software. So all of these poor students, when actually charged with designing a program dealing with, say cashiers, store managers, purchases, reports, etc., start off "well, cashiers and store managers are people, and actually both employees... I guess we need a company object in here", etc.. This almost always leads them into a mess, because they get lost in here before they even learn properly what the goals 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). If they started OO as "modeling reality", just writing a program that does what's needed feels like cheating ("TODO: not really capturing the OO relationships here! rework for v2") -- and that's a bad thing. |