OO question

[fejkadress]

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..
Then maybe I can have a class AddressBook which has a list that
contains all those Address objects.
Does that sound reasonable?
And then the real reason that I posted here is:
If I want to save all addresses to disk, I can have a method, say,
save() of AddressBook. But then what? What is a good object oriented
approach? Should each Address object take care of saving itself to the
file, with a method like writetofile(filename), or should the class
AddressBook take care of the saving and ask each object for its data?

Thanks!

 

[Steven D'Aprano]

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

If you are using Python 2.2 or greater, you can inherit from dict:

.... pass
....

fred = Address({"address": "123 smith street"})
fred['address']

'123 smith street'


But ask yourself, what benefit do you gain by subclassing dict? Why not
just use a dict?

If this is a learning exercise, then sure, go for it, subclass away! But
if this is meant to be real code, then consider what benefits and costs
using OO will give you, compared to a function-based approach.

(Please don't assume that this is a thinly veiled hint that OO is the
wrong approach. It isn't.)

Then maybe I can have a class AddressBook which has a list that
contains all those Address objects.
Does that sound reasonable?

Again, why create an AddressBook class? Why not just have a list of
Addresses?

And then the real reason that I posted here is:
If I want to save all addresses to disk, I can have a method, say,
save() of AddressBook. But then what? What is a good object oriented
approach? Should each Address object take care of saving itself to the
file, with a method like writetofile(filename), or should the class
AddressBook take care of the saving and ask each object for its data?

Here's one approach, assuming that AddressBook is merely a list of
Addresses and that the Address class knows how to write to an open file
object:

def save(list_of_addresses, filename):
f = file(filename, "w")
for address in list_of_addresses:
address.save(f)
f.close()

Here's a more pure OO approach to do the same thing:

class AddressBook(object):
def __init__(self, list_of_addresses):
self.addresses = list_of_addresses

def save(self, filename):
f = file(filename, "w")
for address in self.addresses:
address.save(f)
f.close()

Here's a third approach:

class AddressBook(object):
def __init__(self, list_of_addresses):
self.addresses = list_of_addresses
self.currentfile = None

def save_one_address(self, data):
data = do_something_with(data)
self.currentfile.write(data)

def save(self, filename):
self.currentfile = file(filename, "w")
for address in self.addresses:
self.save_one_address(address.export())
self.currentfile.close()
self.currentfile = None

 

[Paddy]

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

In Python 2.4 or 2.5 you can subclass dict.

like object['name'], etc..
Then maybe I can have a class AddressBook which has a list that
contains all those Address objects.
Does that sound reasonable?

Yep.

class AdressBook(list):
def save(self, filename):
import pickle
...

And then the real reason that I posted here is:
If I want to save all addresses to disk, I can have a method, say,
save() of AddressBook. But then what? What is a good object oriented
approach? Should each Address object take care of saving itself to the
file, with a method like writetofile(filename), or should the class
AddressBook take care of the saving and ask each object for its data?

If you use the pickle module on the Addressbook then it will
automatically
save each Address instance.

- Paddy.

 

[Paddy]

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

If you are using Python 2.2 or greater, you can inherit from dict:

... pass
...

fred = Address({"address": "123 smith street"})
fred['address']

'123 smith street'


But ask yourself, what benefit do you gain by subclassing dict? Why not
just use a dict?

If this is a learning exercise, then sure, go for it, subclass away! But
if this is meant to be real code, then consider what benefits and costs
using OO will give you, compared to a function-based approach.

(Please don't assume that this is a thinly veiled hint that OO is the
wrong approach. It isn't.)

Then maybe I can have a class AddressBook which has a list that
contains all those Address objects.
Does that sound reasonable?

Again, why create an AddressBook class? Why not just have a list of
Addresses?

And then the real reason that I posted here is:
If I want to save all addresses to disk, I can have a method, say,
save() of AddressBook. But then what? What is a good object oriented
approach? Should each Address object take care of saving itself to the
file, with a method like writetofile(filename), or should the class
AddressBook take care of the saving and ask each object for its data?

Here's one approach, assuming that AddressBook is merely a list of
Addresses and that the Address class knows how to write to an open file
object:

def save(list_of_addresses, filename):
f = file(filename, "w")
for address in list_of_addresses:
address.save(f)
f.close()

Here's a more pure OO approach to do the same thing:

class AddressBook(object):
def __init__(self, list_of_addresses):
self.addresses = list_of_addresses

def save(self, filename):
f = file(filename, "w")
for address in self.addresses:
address.save(f)
f.close()

Here's a third approach:

class AddressBook(object):
def __init__(self, list_of_addresses):
self.addresses = list_of_addresses
self.currentfile = None

def save_one_address(self, data):
data = do_something_with(data)
self.currentfile.write(data)

def save(self, filename):
self.currentfile = file(filename, "w")
for address in self.addresses:
self.save_one_address(address.export())
self.currentfile.close()
self.currentfile = None

Small addition.
If a class does a save then it should also do the load of the data too.

 

[John Machin]

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

OK, now you can resume your normal programming ;-)

BTW, why object['name'] and not object.name?

Cheers,
John

 

[Steven D'Aprano]

Small addition.
If a class does a save then it should also do the load of the data too.

What, you've never heard of a write-only file?

 

[robert]

If I want to save all addresses to disk, I can have a method, say,
save() of AddressBook. But then what? What is a good object oriented
approach? Should each Address object take care of saving itself to the
file, with a method like writetofile(filename), or should the class
AddressBook take care of the saving and ask each object for its data?

The OO religion likes to provide a big ego to objects. And be aware! All these egos then want to itch the programmer with question marks for years! And there are programming languages which draw more attention to what some unsolicited objects want, than to what the programmer wants. Python is not so.

Remember, you are the boss. You say: "I want to save all addresses to disk". I'd say: Just dump them to disk unless you feel a functional need in order to make it more indirect.


Robert

 

[fejkadress]

First I want to say thanks everyone for helping me!

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?

 

[Tim Henderson]

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?

Since you are making an address book and not a person book I would
start out by making a simple list of addresses. Each address could have
a "person" or a "name" field. You could then sort your list by the name
of each person associated with each address. If an address has no
person associated with it then you put it at the beginning (or end if
you want) of the list. I think this would most closely mimic how a
rolodex works. It doesn't really matter if you implement it as a list
of dictionaries or a list classes I believe they would be equivalent in
this case.

tim

 

[Paddy]

What, you've never heard of a write-only file?

Ahh /dev/null ;-)

- Paddy.

 

[Dan Sommers]

On 1 Jan 2007 17:09:19 -0800,

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?

I don't know about "a better OO" way, but one way is to model the
various relationships as a list of (person, address) pairs:

persons = [ Person( ), Person( ), Person( ) ]
addresses = [ Address( ), Address( ), Address( ), Address( ) ]

livesat = ((person[ 1 ], address[ 1 ]),
(person[ 2 ], address[ 1 ]),
(person[ 2 ], address[ 2 ]))

worksat = ((person[ 1 ], address[ 3 ]),
(person[ 2 ], address[ 4 ]))

Then the list of people who live at address[ 1 ] is:

[ (person, address) for (p, a) in livesat if a is address[ 1 ] ]

But what about all the various relationships (lives at, works at, is
known to have vandalized, etc.)?

livesat = Relationship( "lives at" )
worksat = Relationship( "works at" )
vandalized = Relationship( "vandalized" )

information = ((person[ 1 ], address[ 1 ], livesat),
(person[ 2 ], address[ 1 ], livesat),
(person[ 2 ], address[ 2 ], livesat),
(person[ 1 ], address[ 3 ], worksat),
(person[ 2 ], address[ 4 ], worksat),
(person[ 1 ], address[ 4 ], vandalized))

Now the list of people who live at address[ 1 ] is:

[ (person, address) for (p, a, r) in information
if a is address[ 1 ] and r is livesat ]

(There are other ways, too, such as capturing one person and one address
right inside a Relationship; someone with a more comp-sci-theoretical
background than I have can probably tell you why or when one way might
be better than the other.)

The definitions of Person, Address, and Relationship, as well as the
user-interface(s) and the persistent storage mechanism(s), are left as
exercises to the interested reader. ;-)

Regards,
Dan

 

[Bruno Desthuilliers]

(e-mail address removed) a écrit :

First I want to say thanks everyone for helping me!

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