OO design

[flupke]

Robert Kern wrote:
> chris wrote:
> 
>> When I think about what I should do I end up with a class XY that has a
>> method for everything I want to do eg.
>>
>> class XY:
>>   def read_file
>>   def scale_data
>>   def plot_data
>>   def shelve_data
>>
>> But somehow that doesn't feel right, especially when I expect the 
>> number of
>> methods will grow and grow, which would make the class very unwieldy.

<snip great advice>


> In short slogans: Just Do It. Make It Work, Then Make It Right. Refactor 
> Mercilessly. Do the Simplest Thing That Could Possibly Work.

+1 QOTW

Very good advice IMO.
I would like to add that for the simpler classes, thinking of how you 
want to use data can be a great starting point.
I recently programmed an interface to a firebird database and said, how 
do i want to be able to use the software?
I thought of this:

table = fb.Table("datafile.fdb","customers")
vals = {}
vals["name"]="customer1"
vals["city"]="mytown"
table.insert(vals)

It looked like a great way to access and use it and it hides all the sql 
details. Well, that's how i started and i had to refactor along the way 
too :)

Regards,
Benedict