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
--
http://mail.python.org/mailman/listinfo/python-list
