Modules instead of Behaviors (was: Generalized Object Modules Design)
Richard A. O'Keefe
ok at cs.otago.ac.nz
Tue Mar 5 23:49:50 UTC 2002
Anthony Hannan <ajh18 at cornell.edu> wrote:
A module is a group of related methods from many classes that fullfill
a single functionality. A module is equivalent to a method category
like 'printing' which may cross many classes. All methods in 'printing'
from all classes would end up in a single module called 'Printing'.
I don't propose to comment on the rest of his proposal.
But this claim is clearly wrong.
If I have some XML classes (and I do), and I have methods for
printing (and I do), they are primarily *about* XML, not *about* printing.
If you loaded the XML classes, you might or might not want the printing
methods; arguably one could chop an XML package up along
common/parsing/printing/visiting lines, with parsing, printing, and
visiting optional.
But if you loaded the "Printing" module in order to print plain text,
you _wouldn't_ want the XML printing methods loaded as well.
We can classify a method several ways:
- what class does it belong to?
- what encapsulation boundary/namespace does it live in?
- what other methods should it be loaded with?
- which of several syntaxes does it use?
- who wrote it/who has permission to revise it?
- which use cases is this needed for?
- what kind of action does this perform?
...
Bertrand Meyer argued for years that classes should be used for
everything, and then Eiffel acquired a notion of "cluster" (more or
less a unit of linking) in its configuration language Lace.
Ada and Common Lisp drive a wedge between classes and packages (which
are encapsulation boundaries), Lisp drives a wedge between both and
units of loading; units of loading can be bigger _or_ smaller than
classes, bigger _or_ smaller than packages.
Because there are many ways to classify fragments of code, it is
unlikely that a single mechanism can serve well for all of them.
While a single mechanism can be very useful for what it does, I
think it unlikely that a mechanism designed without at least
_considering_ the other ways of classifying and structuring will
have staying power.
More information about the Squeak-dev
mailing list
|