lipska the kat <lipskathe...@yahoo.co.uk> writes: > >>>> The ONLY concept that you should never try to encapsulate is/are > >>>> human beings or their aliases.
You stated this in absolute, dogmatic terms. I thought at first you were being hyperbolic for effect, but the situation that you present to support this dogma is one where I can't see anyone rationally concluding the dogma applies. > Well now this is a personal thing born of bitter experience. In my > experience, when you have an entity called 'Person' or some such in > your Class model it soon becomes what we 'in the trade' call a 'God > Object' The name should be self explanatory but hold tight, here comes > some more jargon. God objects are a code smell (another term of art, meaning a symptom in the code that tends to indicate poor design or some other fundamental flaw). But what you're describing below doesn't fit. > Objects can have a 'has a' relationship with other Objects or an 'is a' > relationship with other objects > > The 'has a' relationship means that an Object 'owns' another object, > the is a' relationship means that an Object 'is of a particular type' > Of course in an 'Object Oriented' language such as Java an Object > reference can have a different type at runtime than it does at compile > time. In Python too. > > Anyway, this Person thing soon ends up with a 'has a' relationship > with everything in sight. a Person 'has a[n]' Address, a Person 'has > a[n]' account, a Person 'has a' Doughnut etc etc etc > > Also, inevitably a Person 'is a' Customer, a Person 'is a' Contact, a > Person 'is a' security risk, well you get the idea. This accurately reflects the reality that “person” is a real-world entity very frequently involved in just about anything a typical system needs to model. > Of course this is a problem with the actual design process itself What problem? If the real-world entity really exists and the “has-a” and “is-a” relationships really exist, then it's *good* design to model whatever ones of those are significant to the operation of the program. Indeed, it would be *bad* design to avoid modelling the real world merely because of dogma against modelling persons and their relationships to other entities. If there were entities or relationships that were needlessly cumbersome – if indeed the object was trying to encapsulate the majority of the whole world in itself – then those should be removed from the object, and perhaps even from the design. But that's not what you describe. A Person entity in inheritance or composition relationships with other classes and objects is not a god object, since it is sensibly delegating specific jobs to places other than itself. That's very good, modular design. And when the real domain to be modelled almost certainly has people as a central entity in complex interactions, removing Person from the design entirely is poor work grounded in irrationality. -- \ “I am amazed, O Wall, that you have not collapsed and fallen, | `\ since you must bear the tedious stupidities of so many | _o__) scrawlers.” —anonymous graffiti, Pompeii, 79 CE | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
