/customers/iconara.net/iconara.net/httpd.www/blog/wp-content/plugins/wp-super-cache/wp-cache-phase1.php Iconara » Architectural Atrocities, part 6: No, that is not a singleton

Architectural Atrocities, part 6: No, that is not a singleton

What does the classes Stage, Key, Mouse, Selection, ExternalInterface from the ActionScript 2.0 API:s have in common? They are bastadized singletons.

The really sad part is that of the five, three are still in the API:s in ActionScript 3.0 and of those Mouse and ExternalInterface are still bastardized singletons. Stage has been refactored completely and Key and Selection have been replaced or removed.

The problems

This is what the ActionScript 2.0 API documentation says about the Selection class:

“There is no constructor function for the Selection class, because there can be only one currently focused field at a time.”

There are two problems with this statement:

1. It argues against object oriented development

A class without a constructor isn’t a class. The definition of a class is that it is a blueprint for instances. If you can’t instantiate it, it cannot be a class.

Because of how ActionScript works, both techically and conceptually this “class” is a global object. Conceptually you could even say that Selection is a namespace for a number of functions and global variables.

It may exist a rational explanation as to why Selection works this way, but my money is on laziness. Whatever the reason, the documentation shows that the developers were not very interested in object oriented design, and placed convenience above proper design, which is usually the reason why people use global variables. This violates so many object oriented principles that I’m not even interested in trying to explain them here.

2. It contains a false assumption

That only one field can be selected at a time is perfectly true because that is how the system is designed to work. For now. But will it be true always? Multiple selections in multiple text fields doesn’t seem very far-fetched to me, and if I’m not mistaken you can make discontinuous selections in Word, for example.

It seems someone was short-sighted and made an assumption which, at least potentially, is false. The assumption led to bad design, and a locked-in system. The only way to add discontinuous selection (for example) to ActionScript is to make a new API for selections, or refactor the Selection class, both are not backwards-compatible and require throwing away the existing code.

The same assumption lead to Key and Mouse being treated the same way.

I realise that this isn’t a very big problem, that ActionScript 2.0 is deprecated anyway and that having discontinous selection isn’t a big deal, but it’s still an example of the design and lack of understanding of object oriented methodology which permeates the ActionScript 2.0 API:s. That ActionScript 2.0 is deprecated show just how bad it is, the only way to move forward was to chuck the whole system and create it all from scratch.

More examples

The Mouse and Key class are similar and they both deal with input events. A proper architecture might have included an interface all input devices implemented, it would define common functionality and make it possible to code your own input device. An example could be a virtual device which got its input from a network socket, or the motion sensor in many new laptops.

However, the mouse and keyboard are still suitable candidates for singletons, since in all operating systems I have used besides Amiga, you can only have one mouse and one keyboard — with a proper architecture a future system (or an Amiga) with two mouses could also be supported.

The ExternalInterface is also just a collection of functions, and it is new in Flash 8, which means that it cannot be excused on the grounds that it has always been like that.


Strictly speaking, the Stage, Key, Mouse, Selection and ExternalInterface are actually not examples of the singleton design pattern, but of Monostate. A monostate is an object which saves its state in static variables, thus making every instance identical. You can find more information on this pattern at the Portland Pattern Repository. The patterns are related and can be argued to be two aspects of the same (only Singleton appears in the GoF book). Monostate puts the emphasis on having a single state, whereas Singleton (in it’s global variable aspect) is about enforcing a single instance. You could say that Monostate takes the bad parts of Singleton and makes them worse.


The singleton design pattern is arguably the most debated and the most mis-used design pattern of them all, and the Macromedia/Adobe developers aren’t shy to use the worst of it.

I will try to write up a post on the proper use of the singleton design pattern shortly. I believe that it is a powerful and important pattern, and that it has been accused of too much bad things because of ignorant developers.

2 Responses to “Architectural Atrocities, part 6: No, that is not a singleton”

  1. Todd Clark Says:

    O.k., I read the page about the singleton problem so I’m probably about to aska really stupid question. Is there anyway to get around this problem and make more than one instance of a specific class? or do I really have to make a seperate class for al of my a.i./enemies? Or is it possible to just extend the MovieClip class and make multiple instances of that?

  2. Theo Says:

    I’m sorry, I don’t understand the question.

Leave a Reply