Smalltalk and Object Orientation: an Introduction - Free

The one exception to this rule are subclasses of Object. This is because Object is the root class
of all classes in Smalltalk and as you must create a new class by subclassing it from an existing class, it
is typical to subclass off Object when there is no existing appropriate class.
24.3.3 Capabilities of a subclass/class
A subclass or class should accomplish one specific purpose, that is it should capture only one idea. If
more than one idea is encapsulated in a class you may be reducing the chances for reuse as well as
contravening the laws of encapsulation in object oriented systems. For example, you may have merged
two concepts together so that one can directly access the data of another. This is rarely desirable.
This guideline leads to small classes (in terms of methods, instan ce variables and code). Breaking a
class down costs little but may produce major gains in reusability and flexibility. If you find that when
you try and separate one class into two or more classes, some of the code needs to be duplicated for
each class, then the use of abstract classes can also be very helpful. By placing the common code into a
common abstract superclass, you may be able to avoid unnecessary duplication of that code.
The following two guidelines are intended as an aid in identifying when a class should be split:
1. Look in the class comment (if there is no class comment than this is a bad sign in itself). Consider the
following points:
• Is the comment short and clear. If not is this a reflection on the class? If it is, then consider how
the comment can be broken down into a series of short clear comments. Now base the new
classes around these comments.
• If the comment is short and clear, do the class and instance variables make sense within the
context of the comment? If they do not, then the class needs to re -evaluated. It may be that the
comment is inappropriate, or the class and instance variables inappropriate.
• If the comment is short and clear, do the class and instance methods make sense within the
context of the comment? Again if they do not then appropriate action should be taken.
2. Look at the instance variable references (i.e. look at where the instance variable access methods are
used). How are the instance variables being used? Is their use in line with the class comment?
Again, if the answer to this is no, then appropriate action should be taken.
24.3.4 Changes to system classes
In general attempts should be made to avoid making changes to system classes if at all possible. Such
changes can produce surprising side effects as well a reduc e the portability of your code and others. In
addition you may find it difficult to support the changes you have made to the system classes in future
releases of the system.
However, there are certain circumstances in which it is necessary and useful to extend system
classes. However, it is an extremely bad idea to modify an existing method of a system class. This is
because if you are not absolutely sure about what you are doing you can affect the behaviour of very
many objects. If you really feel you have to modify an existing class’s method(s), then it is much better
to subclass off the existing system class and modify the method(s) behaviour(s) there. Then if you do
something which has unanticipated effects, those effects are localized.
If you are merely adding new methods to an existing system class, then it is a very good idea to
place your additions in a separate category. This means that not only is it easier to find these additions,
but that you can file out the category to a different file so that w hen updates to the system are delivered,
you can easily patch in your extensions.
24.3.5 Creating new collection classes
When working with collections, there is always the question of whether to subclass a new collection
class to hold your data (as we did for th e Queue and Stack classes) or whether to define a non
collection class which will hold a collection within one of its instance variables and then provide
methods which will access that instance variable. For example, let us assume that we wish to define a
new class called account, which will hold information on deposits and withdrawals. We believe that we
198