OO design

[Caleb Hattingh]

Chris

> 1. get arbitrary numerical data (typically large data sets in columnar
> format or even via COM from other packages. I generally have to deal with
> one or more sets of X,Y data)
> 2. manipulate the data (scaling, least squares fitting, means, peaks,
> add/subtract one XY set from another etc)
> 3. plot data (original set, results of manipulation, scatterplot,  
> histograms
> etc  - I use matplotlib)

Matplotlib is really coming on.  I still use gnuplot out of familiarity  
(and features, to be sure) but one of these days I'm going to spend a bit  
of time on Matplotlib.

> 4. export data (print, csv, shelve)

I do very much the same kind of work with python.  I write mostly in  
Delphi at work, but for processing stuff like this, I always use python  
when the dataset is not too big and the processing of the data is not too  
expensive.  Despite the awesome Delphi IDE, python with a text editor is  
*still* more productive (for *me*) in jobs like this.

> I have no problem writing bits of functional code to do any of the above.
> But for the life of me I can't see how I can hook them altogether in an  
> OO
> based framework that I can build and extend (with more data formats,
> manipulations, GUI etc).

To be honest, I am probably a poor source of advice here because I think I  
tend to overuse the class paradigm when often a more sensible approach  
would be a top-down strategy.   I just tend to think in terms of objects,  
for better or worse.  At least python's class declarations are not  
expensive in terms of setting up, so I tell myself it's ok.

Lets look at what you suggested:

> class XY:
>   def read_file
>   def scale_data
>   def plot_data
>   def shelve_data

This is exactly the kind of thing I do as well, but maybe separate the  
dataset from the processing (and put the classes into separate files, if  
you prefer - I find the "one class per file" idea easier to manage in my  
editor , Vim)

class XYpoint(object):
	def __init__(self,x=0,y=0):
		self.x = x
		self.y = y

class Dataset(object):
	def __init__(self):
		self.data = [] # Will be a list of XYpoint objects - probably filled in  
with Gather?
	def Gather(self,source):
		pass # You fill this in, using source as you prefer
	def Scale(self,factorX,factorY): # Filled out with example implementation  
below
		for i in range(len(self.data)):
			self.data[i].x = self.data[i].x * factorX
			self.data[i].y = self.data[i].y * factorY
	def Plot(self):
		pass # Do what you gotta do
	def Shelve(self):
		pass # Do what you gotta do

class MultipleDatasets(object):
	def __init__(self):
		self.datasets = [] # Will be a list of dataset objects, which you must  
populate
	def PlotAll(self):
		for i in self.datasets:
			i.Plot # How to plot all your datasets, for example

[FWIW - This is how I write all my python programs - very very naively and  
simply.  I just cannot remember all the fancy things enough to use when I  
need to get something done.  This is the kind of simple syntax that lured  
me to python in the first place, and I have a disconcerting feeling about  
all the "advanced" features for "master" programmers creeping into the  
language lately, or at least getting discussed - I don't think I am smart  
enough to absorb it all - CS isn't my area]

> 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 would be interested to know if you think what I wrote "feels" right to  
you or not - It certainly feels "right" to me, but then that is hardly  
surprising.  In any case, what I presented almost exactly fits how I  
"think" about the problem, and that is what I want.

> bwaha.

?

regards
Caleb