OO design

[Robert Kern]

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.

I think that a key thing to remember, especially as you start learning 
OO design, is to not succumb to analysis paralysis. If all you need 
right now are those four methods, then implement those four methods. You 
don't know what the other 16 methods are going to be, so don't bother 
with them yet. When you do end up with the groaning, 20-method behemoth 
(and you will), then you will have a better idea of what capabilities 
you need and who needs to talk to whom.

At this point, you refactor. Do not fear the refactoring. Embrace it. 
There's much to be said for just getting it right the first time, but 
let's face it: it never happens because what's "right" is rarely known 
at the beginning of a project. Eventually, as you accumulate experience 
and find designs that work and ones that don't, you'll begin to have a 
better idea of what's "right" ahead of time and your initial designs are 
going to get better and better. But for now, don't let the fear of bad 
design prevent you from writing code. We all do bad designs; we just fix 
them later.

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

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter