2.1 From Where to Start? ¶

Design by reuse indeed, but from where to start? Which classes should we reuse? As often, the Cuis-Smalltalk system may be our best guide; let’s interrogate it to learn which morph has more subclasses.

We collect, for each existing morph in the Cuis-Smalltalk system, the number of subclasses, then we sort the result.

| hallOfFame |
hallOfFame := Morph allSubclasses collect: [:each |
   Array with: each with: each subclasses size].
hallOfFame := hallOfFame sort: [:array1 :array2 | array1 second > array2 second]

Figure 2.1: The hall of fame of morph subclasses count

Let’s analyze some top-ranked morphs:

1. PlacedMorph. Its subclasses need to override the drawOn: method, so it’s not a candidate for designing morphs by reuse.
2. BorderedMorph, ColoredBoxMorph, and BoxMorph. These classes are PlacedMorph with a few additional characteristics. Subclassing these classes will most of the time require overriding the drawOn: method.
3. LinearLayoutMorph. It has 11 subclasses. It is designed to assemble morphs into a new morph. Using this class for reuse makes perfect sense, and we already know how to use it.
4. SystemWindow. As a view representing a whole application, subclassing it makes sense to implement specific behaviors of a GUI application, but not as a morph you can reuse as a widget.
5. PluggableMorph. It seems very generic and may be a good candidate. It represents a view of an associated model. However, its subclasses need to implement a specific drawOn: method. We may want to use it when designing a morph from scratch.
6. PluggableScrollPane. This morph encapsulates an arbitrary morph – called a scroller – in a pane with optional scrollbars when the scroller extent is too large. It is very handy, and in some circumstances it makes sense to subclass it.

All in all, we have two candidates to subclass when conceiving a morph by reuse: LinearLayoutMorph and PluggableScrollPane.