bdesth.quelquechose at free.quelquepart.fr
Tue Jan 2 16:32:12 CET 2007
fejkadress at hushmail.com a écrit :
> First I want to say thanks everyone for helping me!
> John Machin wrote:
>>fejkadress at hushmail.com wrote:
>>>I want to make an addressbook and I'm new to OO programming, so I
>>>wonder if this sounds reasonable.
>>>I think of making a class Address which contains all data about one
>>>person, that class can have UserDict as baseclass so I can access data
>>>like object['name'], etc..
>>Stop right there. Class Address contains all data about one *person*?
>>Please consider renaming that class Person, and having a separate class
>>Interruption for a reality check: A person may be related to zero, one
>>or many addresses. An address may be related to zero, one or many
>>persons. The relationship may take many forms e.g. "lives at", "once
>>lived at", "has been noticed loitering outside", ...
> Lets say I have those two classes, Person and Address. How would one
> implement the relationship between them? First, a Person can have one
> or more addresses (or none), that could be represented as a list of
> Addresses, right? But then, if I have an Address I want to see which
> persons who live there, then I would have a list of Persons in each
> Is this doubly-linked way of doing it a good way of doing it, or is
> there a better "OO way" I haven't learned yet?
The most common solution so far for this kind of problems is to forget
about "domain model" OO modeling and switch to relational modeling
(usually using an SQL dbms). Else you end up rewriting an half-backed
buggy ad-hoc relational system... FWIW, using OO does not imply using an
OO domain model. You can restrict OO features to "technical" objects...
Now the good news is that there are Python packages like SQLAlchemy that
gives you kind of "best of both world" solutions (OO domain model +
My 2 cents...
More information about the Python-list