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