[newbie] Looking for a good introduction to object oriented programming with Python

[Ben Finney]

lipska the kat <lipskathekat at 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