Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Design with Singletons in Squeak
The following provides a small overview of the implementation of a Singleton design within Squeak as well as the problems held therin.
Memory Management and you
Squeak's Memory Management involves a simple reference counting system. When something is no longer being referenced, it dies. This causes problems with Singletons since they, in essence, create global objects. Our team worked around this by adding methods within the Singleton classes to destroy their instances and everything inside them as well as methods to ensure that all references to the instance were destroyed.
Only the lazy need apply
In C++ and Java, among other languages, it is possible to create a Singleton that instantiates itself when the application begins. This allows the removal of Lazy checking when calling the getInstance method of the Singleton class. However, Squeak is more like an Operating System and, as such, the preferred method became to use the Lazy method for instantiation:
"Return the current instance of the Singleton"
Instance ifNil: [
Instance := super new.
Note that the Lazy method is defined by the fact that the Instance is "lazily" instantiated by creating it only when used.
Instance initialize? NO!
In Squeak, the initialize method is called when the object is instantiated. Because of this, it became impossible to use an initialize in the Singleton because it was not a traditional object, per se. The problem arose in the form of infinite loops as well as other fun errors involving new. Hence, the buildUp method is used to initialize the Singleton in our code.
"This is called from to instantiate any necessary variables"
gameMessages := MessageQueue new.
locationList := Bag new.
tagName := 'GameEngine'.
doRun := nil.
The problems with Papa Singleton
In C++, it is possible to use templated classes to create a master Singleton and then proceed to use the template to create all other Singletons. This is not possible in Java or Squeak, forcing each Singleton to be rewritten (resulting in a disturbing trend of copying/pasting common code). The problem lies in the fact that the inherited Singleton's instance will simply be the same one as its parent's. This causes a plethora of problems, of course, which made the inheritence more work than it was worth. There was no way around this from our perspective and, as such, it became the preferred method of attack.
Seriously, over-use of any design pattern is a bad thing, however, in terms of the design for the Game, it became obvious that using the Singleton would greatly increase the modularity and abstraction of the code. There is only 1 GameEngine, there is only 1 World, there is only 1 view. Being the totalitarian designers that we are, this led to the Singleton design which allowed for each team member to work independently of the others and kept everyone's toes safe.
There were, of course, issues. In the development of the game, there were issues in the flushing of data due to the Singleton design and Squeak's memory management (this, of course, being the same issue encountered previously with Java). However, the advantages greatly outweigh the inconveniences of the peculiarities of the design.
Singletons am cool.
Links to this Page
- Team OTIB OS last edited on 5 December 2004 at 10:01 pm by helsinki.cc.gatech.edu
- M3_OTIB last edited on 4 December 2004 at 2:36 am by turku.cc.gatech.edu