Summary | 125Figure 3-7 also shows the Output window with theghostCart instance adding
another $25.33 for a total of $35.39. The final total is simply the sum of 25.33 and
10.06. The $10.06 value is the amount in themyCartreference, and, added to the
amount in theghostCart reference, we arrive at 35.39, just as predicted.
Summary
The Singleton focuses on ensuring that only a single instance of a class is instanti-
ated and having global access to the class of the Singleton’s origin. While certain
aspects of the Singleton appear simple, other features show it to be a subtle and com-
ple xdesign pattern. To be sure, one can find more than one way to design a Single-
ton, and the ones developed for this chapter certainly have no claim to originality.
However, they do represent a very standard implementation of the Singleton, and
one that resolves some of the unique elements of ActionScript 3.0 specifically, and
ECMAScript more generally.
The Singleton, especially the “classic” model on which we based the ones used in
this chapter, has well-reasoned detractors. A short search of design pattern books
and articles, including many excellent ones available online, finds many different
ideas of how to best design a Singleton class or wholly replace it with a different con-
ceptual structure. The fact that the Singleton provokes such thought has merit in its
own right, and we certainly have wrestled with certain limitations ourselves. So if
you’ve got a better Singleton design or better alternative, by all means pursue it.
The most common complaint about the Singleton is its incorrect use, or use in a con-
text where it gets in the way of flexibility and reusability. Another complaint is that
the pattern’s overused. Some of the overuse can be attributed to its simplicity, but
overuse also happens when people don’t fully understand the pattern. One reason
we provided so many different examples of the Singleton is to show that it does have
clear uses. As a rule of thumb—do not use the Singleton where a good deal of change
and reusability are likely. A Singleton’s purpose is clear—limiting one and only one
instantiation, and providing a global entry point. Beyond that, they have limited util-
ity, and while popular as part of more robust design patterns, you must be careful
not to let them get in the way of another pattern’s utility.
However, as we have demonstrated in this chapter, the Singleton has some very prac-
tical uses, and you should never lose sight of that. Like all design patterns, the Single-
ton’s only redeeming purpose is to accomplish certain recurring programming tasks.
The fact that you can’t use it every time these tasks appear to be necessary does not
mean it’s been rendered obsolete. Rather, it means simply that the Singleton isn’t the
best way to do it. These tasks, especially common ones, should either serve to
prompt adaptation of the Singleton, use another design pattern, or develop and
adjust certain aspects of the classical Singleton design.