On 07/08/12 14:12, Ben Finney wrote:
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.
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
--
http://mail.python.org/mailman/listinfo/python-list
