Navigation:  Appendix B: Dolphin Pattern Book > Global Variable Patterns >

Global Variable

Previous pageReturn to chapter overviewNext page

Context

Global variables in Smalltalk exist in a single global namespace, the Smalltalk dictionary. They provide access to an object from any class in the image but, in general they are frowned upon because they:

violate the object oriented principle of data encapsulation
create hidden dependencies between classes
reduce the portability of applications due to namespace issues
create ownership and object lifetime issues

So when should we decide to create a new global variable?

Solution

Probably never. Under normal circumstances you probably shouldn't add any global variables (apart from classes, which are global by definition). There are several alternatives: Pool Dictionaries, Class Variables and Class Instance Variables each of which have their own particular advantages and relieve the pressure on the global namespace.

1.Pool Dictionaries hold groups of constants for an application. Pool Dictionaries can be referenced by any instances of any class which has specified the Pool Dictionary in its class definition. These classes can be unrelated.
2.Class Variables are available to all instances of a class and all instances of all of its subclasses.
3.Class Instance Variables are similar to Class Variables except every subclass (and its instances) has its own copy of the variable.

Known Uses

The View hierarchy uses a Pool Dictionary called Win32Constants which holds all of the Windows specific constants. These are available to all instances of View and all instances of all of its subclasses.
The Behavior class defines a class variable called PointersMask which holds a flag mask that can be used to test whether an object holds bytes or pointers.
The ExternalLibrary class defines a class instance variable called default which, for each subclass, is the default instance of that subclass (Singleton)

Related Patterns

Global Name