"Eddie Cottongim" <cottonsqueak at earthlink.net> wrote:
> 1) I have an object which relies on subclasses of another class, we'll call
> it AbstractHeavyLifter, to do some work. I want to be able to give a user a
> choice of all the kinds of HeavyLifter available, and I don't want to
> hard-code which ones they can use, since they could add new ones, etc. What
> I do right now is get all the subclasses of AbstractHeavyLifter and ask each
> one if I can use it in menus (abstract classes will want to say No here).
> This is how the Morph menus work, and I'm 90% sure its the Right Thing, but
> I wanted to check and make sure.
> 

Well, I don't think it's proper to search through the system's code to
figure out what to do.

First, you shouldn't have to put the heavy lifters in a particular place
in the hierarchy.  This is Smalltalk, and you can subclass anywhere you
please.

Second, this allows merely *adding* a subclass to change the behavior of
the system, even if you haven't explicitly mentioned that subclass
anywhere.  I don't like this, though it's a philosophical reason more
than anything: changes to *behavior* should be done by changing methods,
not changing classes.  Adding classes is a way to declare a new kind of
thing that *can* be created.

Finally, a very pragmatic reason to avoid code like this is that the
code exploration tools don't deel so well with it.  In particular, "show
uses of this class" will return no uses for the HeavyLifter subclasses!

Here's an alternative: make a method somewhere listing all of the
available HeavyLifter's:

	AbstractHeavyLifter class>>standardHeavyLifters
		^{HeavyLifter1. HeavyLifter2. HeavyrLifter3 }


This list is easy to mantain.  It allows the lifter classes to live
anywhere in the class hierarchy.  Adding classes no longer causes
changes to occur.  And "show uses of this class" will now point to this
method, which will greatly help anyone trying to understand the code.

To get mystical, I think your code should say what it wants as directly
as is reasonable, and it should *not* mix up different concepts.  The
list of available classes should not be mixed up with the the list of
classes available for a specific purpose.


-Lex