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

lipska the kat lipskathekat at yahoo.co.uk
Tue Aug 7 10:13:05 EDT 2012


On 07/08/12 14:12, Ben Finney wrote:
> 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.

Ah, you mean you don't agree.

>> Well now this is a personal thing born of bitter experience.

[snip]

>> 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.

No, you are wrong. Having a Person class is profoundly and fundamentally 
wrong. If we follow this argument then every system ever modelled would 
have a Person at it's heart.

I think you are missing the point here. You say.

 > This accurately reflects the reality that “person” is a real-world
 > entity very frequently involved in just about anything a typical stem
 > needs to model. that a "person" is a real-world entity very >frequently

Have asserted that you are profoundly wrong I now have to say that I 
couldn't agree more BUT with the crucial modifier that a person is an 
"actor" I don't care if you like or dislike the terminology, you get the 
general idea. An actor exists outside the system. Having a Person in the 
Class model tends to blur the boundaries between system and users. I 
know it does, I've seen it happen so many times.

It's all about how we think about a system in the early stages of design
The moment we introduce a Person (or alias for a Person) we confuse our 
thinking, are we thinking about Person as actor or are we thinking about 
Person as entity in our system. This is not some nebulous flight of 
fancy, this is born of real world, stand at the whiteboard and thrash 
out a design experience. I have been ridiculed before, strangely enough, 
once the Person has been expunged from the system mind things go a whole 
lot more smoothly.

>> 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.

Dogma is an emotive word that you are using to belittle the idea. That's 
fine, you asked me to explain myself and I have done so.

[snip]

> 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.

Well I say it's sound judgment grounded in experience and most if not 
all my employers seem to agree. I have thousands of lines of code 'in 
the wild' operating without fault day after week after year and not one 
single line refers to, implies or otherwise represents a "Person" in any 
way whatsoever.

Just one tiny point, I NEVER have to 'remove' a Person from my designs 
as they never get through the door in the first place.

The only time I have ever had to agree that a "Person" belongs in a 
computer is when I saw Tron.

lipska

-- 
Lipska the Kat: Troll hunter, sandbox destroyer
and farscape dreamer of Aeryn Sun



More information about the Python-list mailing list