Organisation of python classes and their methods

[Ulrich Eckhardt]

Am 02.11.2012 09:20, schrieb Martin Hewitson:
> Well, here we disagree. Suppose I have a class which encapsulates
> time-series data. Below is a list of the absolute minimum methods one
> would have to process that data.
[...]
 > 'abs' 'acos' 'asin' 'atan' 'atan2' 'average' 'cohere' 'conv' 'corr'
 > 'cos' 'cov' 'cpsd' 'detrend' 'dft' 'diff' 'downsample' 'exp'
 > 'export' 'fft' 'fftfilt' 'filter' 'filtfilt' 'find' 'heterodyne'
 > 'hist' 'imag' 'integrate' 'interp' 'join' 'le' 'lincom' 'ln' 'load'
 > 'log' 'log10' 'lscov' 'max' 'mean' 'median' 'min' 'minus' 'mode'
 > 'mpower' 'mrdivide' 'mtimes' 'ne' 'norm' 'or' 'plot' 'plus'
 > 'polyfit' 'power' 'psd' 'rdivide' 'real' 'resample' 'rms' 'round'
 > 'save' 'scale' 'search' 'select' 'sin' 'smoother' 'sort'
 > 'spectrogram' 'split' 'sqrt' 'std' 'sum' 'sumjoin' 'svd' 'tan' 'tfe'
 > 'timeaverage' 'times' 'timeshift' 'transpose' 'uminus' 'upsample'
 > 'zeropad'


Just as a suggestion, you can separate these into categories:

1. Things that modify the data, yielding a different (although derived) 
data set, e.g. import/load, split, join, plus, minus, zeropad.
2. Things that operate on the data without modifying it, e.g. 
export/save, average, find, plot, integrate.

The latter can easily be removed from the class. Since they don't touch 
the content, they can't invalidate internals and can't break encapsulation.

For the former, providing general means to construct or modify the data 
(like e.g. adding records or joining sequences) is also all that needs 
to remain inside the class to ensure internal consistency, everything 
else can be built on top of these using external functions.


Uli