Smalltalk and Object Orientation: an Introduction - Free

should use a dictionary to hold the actual data, but should Account be a subclass of Dictionary or
a subclass of something else (for example Object)? The two options are illustrated below:
Object
Account has in an instance variable holding an instance of class Dictionary
or would it be better to have:
Object
Dictionary
Account
Of course this point also depends on what you are going to do with the Account class. If it is
providing a new collection class (in some way) even if it is only for your application, then the above
should be born in mind. However, if what you are actually doing, is providing a functionally complex
class which just happens to contain a dictionary, then the above would be the wrong way to do it. In this
case it is almost certainly better to make the new class a subclass of Object.
There are two further points to bear in mind about this. The first is tha t if you define any instance
variables in Account, then when you examine any instance of Account you will find that you get the
Dictionary inspector which does not display the instance variables. This can be quite infuriating. Of
course you can subclass th e inspector and extend it so that it does display the instance variables. A
second point is that if an instance of Account needs to grow, then the contents of the instance
variables defined in Account will apparently disappear, unless you extend the copyEmpty method it
will have inherited. This method must be extended such that the contents of the instance variables is
copied. Again, this is only a minor point, but can be extremely annoying when you have spent a great
deal of time attempting to track down a bizarre bug, only to find this is the root cause of your problem.
24.3.6 Class comments
Every class should have a class comment, no matter whether it is an abstract or concrete class. This
comment should act as the basic documentation for the class. It should th erefore tell both a developer
subclassing from the class, or a user of the class, what they need to know. The comment may also
contain information about the author’s name, affiliation, history of the class’s modifications, as well as
its purpose and status . Information which might be placed in the class comment includes the name of
the class author, its purpose, who has modified the class, when and why, the type of class, instance and
class variables (including the class of object they will hold and their use), collaborations between this
class and others, example usage, copyright information and class specific information such as what a
subclass of an abstract class is expected to redefine.
24.3.7 A class or an instance
In some situations it may only ever be nec essary to create a single instance of a class. This single
instance must be created and then referenced where it is required. A point of continued debate is
whether it is worth creating such an instance or whether it is better to define the required behavi our in
class methods and reference the class (after all a class is an object as well). Invariably the answer to this
is no, for the following reasons:
• Such an approach breaks the standards which have been set, not only in the VisualWorks image,
but by the majority of Smalltalk developers. You will therefore be reducing the readability and
comprehensibility of your system.
• The creation of an instance requires a minimum of overhead. After all this is a key feature in
Smalltalk and it has therefore received extensive attention.
• You may require more than one instance sometime in the future. If you have implemented all the
code on the class side, it will be necessary to move these methods onto the instance side of the
class.
• In doing so, you may be tempted to tr eat the class as a global reference. This suggests that the
implementation has been poorly thought out.
199