Smalltalk and Object Orientation: an Introduction - Free

Temporary variables, which ar e local to a method, often have a mixture of semantic and typed
names. Larger methods often have semantic local variable names due to the additional complexity they
represent.
Table 24.1: Variable naming conventions
Variable type Convention Variable type Convention
Global variable Capitalized Temporary variables Lower case
Class variable Capitalized Class instance variables Lower case
Class names Capitalized Instance variables Lower case
Pool variables Capitalized Method parameters Lower case
In addition, if the variable name is made up of more than one word, the words should not be
separated by ‘-’ or ‘_’, but by the capitalization of the first letter of all but the first word. For example:
theDateToday
employeeRecord
objectInList
Whether the first word in the variable is capitalized or not depends on the type of variable being
used. Table 24.1 summarizes the conventions.
24.2.2 The role of variables
Instance variables , class variables and class instance variables all play particular roles within a
Smalltalk system:
Instance variables should only be used for holding local data or for holding references to other objects.
In the latter cas e, these other objects should be involved in some form of collaboration with the
object (otherwise why does the object have a reference to them).
Class variables should only be used as ‘constant’ values which are referenced by all instances of a
class. They should never be used as a form of limited global variable. Such a use is frequently an
indication that a solution has not been designed with the proper amount of care and attention. A
very nice use of class variable can be found in the database classes of VisualWorks.
Class instance variables are often ignored by most Smalltalk programmers because they are not sure
what to do with them. This is partly due to the lack of their use in much of the VisualWorks
image and partly due to the rarity of occasions when their use is justified. A class instance
variable, is a local variable for the class. They are only accessible by the class itself and each
class will hold its own copy of the data.
Class instance variables should only be used when either:
• classes need to hold some local data which instances should not have access to (otherwise use
a class variable)
• each class in a particular class hierarchy needs to hold its own copy of some data whi ch
should not be shared with other classes.
If you wish to see an example of their use look up UILookPolicy in the VisualWorks image.
24.2.3 The role of pool variables
Pool variables are global variables whose scope is limited to those classes which have (explicitly) joined
the pool. They should not be used as a cheap way of sharing information amongst a disparate set of
classes (for example as a means of providing a global variable without the stigma of a truly global
variable). In general their use is really on ly justifiable within an application framework (a set of
cooperating objects of different classes). Such frameworks often require some common shared values.
For example, the text style to use in an application, the name of a preference file or the settings obtained
from such a file. Pool variables can then be used to record this information once, but allow it to be used
by all the objects within the framework.
196