"Eddie Cottongim" cottonsqueak@earthlink.net wrote:
- 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
squeak-dev@lists.squeakfoundation.org