OO design

corey.coughlin at comcast.net corey.coughlin at comcast.net
Tue Jul 19 20:28:57 EDT 2005


I also have a little trouble with creating megaclasses.  Usually I just
try to think about what things are a little bit, and how I'm going to
be using them.  I think somebody else suggested a top down approach,
and that makes a certain amount of sense.

But at this point, you're probably getting tired of all the vague
advice.  It sounds like you don't have a very complicated set of
concepts to deal with, so you probably won't wind up with too many
classes, but having a single giant one is probably inconvenient.
Here's how I would do things (although keep in mind, I only have a
vague understanding of what you really need to do..)

First off, you have your (x,y) datasets.  It sounds like you perform
most of your operations on those, so they'd probably be a good idea for
a class.

You may also want a class for the (x,y) points themselves, especially
if you have any operations that collapse a point set to a single value
or values (like your means and peaks and stuff.)

So the methods on your (x,y) dataset probably want to be restricted to
your mathematical operations.  Although you'll also definitely want to
look at the representation that gets passed onto your other classes.

Thinking beyond those basic classes, you probably want to now think
about your input and output operations.  A general way of doing OOP for
things like this is to try to abstract your input and output operations
into objects based on what kinds of inputs or outputs they are.  In
this case it sounds like you have files, which are both input and
output, and plots, which are just output.  Both seem to take either
single x,y sets or a number of sets.  So each I/O object would appear
to be some sort of object container for your x,y sets.

Take the plot object.  It will probably be fairly simple, just
something you pass sets of x,y lists to and it plots them.  You may
want some more capabilities, like naming the sets, or giving the axes
units, or whatever, but you can probably add that stuff later.

Now for the file object.  Luckily, python already includes a file
object, so you already have something to base yours on.  For the files,
you have two basic operations, the read and the write.  For the read,
you'll need to pass in a filename, and have a way to return the
datasets (like iterating over a data file produces a dataset, hm...).
For output, you'll again need a filename, and a set of datasets to
write.  For both operations, you may also want to provide formatting
options, unless you can figure it out from the filename or something.
So the ultimate hierarchy might look something like this:

class point:
    self.x
    self.y

class dataset:
    self.data = [ #list of points ]
    self.units = '' #?? maybe
    def sum
    def mean
    # and so on

class datafile:
    self.filename
    self.filetype
    self.datasets = [ #list of data sets? ]
    def read
    def write
    ## and so on

class plot:
    self.datasets = { #dictionary of data sets, each named?}
    self.xaxis = ''
    self.yaxis = ''
    def makeplot
    ## and so on

Looking at it like that, it might make some sense to come up with
something like a dataset collection class that you can pass to plot or
datafile, but if you can use something like a list (if the data is
fairly arbitrary) or a dictionary (if the datasets have names or some
other way of signifying what they're about), that will probably be
enough.   Anyway, that's just a rough sketch, hopefully it will give
you some ideas if it doesn't seem like the best solution.




More information about the Python-list mailing list