Appendix B: Dolphin Pattern Book > Global Variable Patterns >
variables in Smalltalk exist in a single global namespace, the . 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?
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.|
|•||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)|