[EMAIL PROTECTED] a écrit : > First I want to say thanks everyone for helping me! > > John Machin wrote: > > >>[EMAIL PROTECTED] 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 >>Address. >> >>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 > Address. > > 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 + relational support). My 2 cents... -- http://mail.python.org/mailman/listinfo/python-list
