By paddloPayday loans

Home > Singleton > Saint Singleton: Have We Martyred a Design Pattern Unfairly?

Saint Singleton: Have We Martyred a Design Pattern Unfairly?

Saint Singleton

Saint Singleton

In our book, I wrote the chapter on the Singleton Design Pattern, and on this blog I penned the post entitled, Singletons Give You Pimples. My comments were based on several articles (including one similarly named!) I had read on why to avoid the Singleton and the 2006 OOPSLA meetings in Portland, Oregon. Of the articles available online that detail the problems with the Singleton Miško Hevery’s blog post, Singletons are Pathological Liars is the most detailed, but Scott Densmore’s article, Why Singletons are Evil is an equally convincing—and succinct— argument why we should keep our distance from Singletons.

Even Erich Gamma was quoted as lamenting the fact that they included the Singleton in their Design Pattern book. There’s not a lot more that I can say than I did in my ranting post on Stinkin’ Singletons, and you can find tons more online.

Is There Salvation?

Recently on this blog, my old friend aYo Binite (who got me involved in ActionScript 3.0 design patterns in the first place) suggested that the Singleton wasn’t as bad as I made it out to be. Naturally, I replied with a reasonable argument comparing them to skin-eating viruses, pedophiles, and Nazis. aYo said that the jury was still out, and I wondered, ‘What jury?’ All in all, though, I may have been as unfair to the Singleton as the Roman emperor Diocletian was to Saint Sebastian. (Diocletian first had Sebastian used for archery practice and left him for dead. Then when the emperor found that he had survived—he had Sebastian beaten to death and thrown into a crapper.) Naturally, I don’t want to be equated with the touchy Diocletian, and so I’m offering up an opportunity for comments by our readers to either help pull the Singleton out of the crapper or shoot another arrow into the misguided design pattern. The Comment Section is Open!

Categories: Singleton
  1. aYo
    September 1, 2009 at 9:43 am | #1

    :) I’m flattered to have touched a chord Bill. There are inherent problems with the Singleton as indeed there are with other software patterns. Having said that a lot of the bad press accorded the Singleton is due to ill use rather than the poor structure of the pattern per se. I think the real issue here is the actual usage of the pattern or of its expectations – in too many cases it has been used as a plaster to fix coding deficiencies. I think the structure of every application needs to be carefully thought out before creating its solutions and scaffolding. Under those circumstances if the Singleton fits use it, if on the other hand there are better options then use them. :).
    I’m just open to what makes things work better, I take no sides.

  2. September 1, 2009 at 11:57 am | #2

    Hi aYo,

    I don’t think this is a matter of misuse. Rather, the Singleton is fundamentally flawed. (Indeed, it can be misused, but that’s another issue.) Scott Densmore best sums it up with four key flaws:

    1. Acts like global variables
    2. Violates the single responsibility rule
    3. Promotes tight coupling
    4. Carries state as long as the program lasts

    It’s not like you’re going to use a Singleton and have a program crash every other use. Rather, when it comes time to update (which can be often!), re-use, or de-bug a program, the Singleton can seriously get in the way.

    For me, it’s like introducing a virus to your own system. Why do it when it is wholly unnecessary? The programmers at Google are even given a “Singleton Detector” utility to make sure none of their programs have Singletons.

    As yet, I’ve never encountered a program where I thought, “If I only had a Singleton, I could solve this problem!” On one blog, a post advised “Stay off of Singletons for one year.” I’ve been off them for several years and have not missed them once.

    Take care,

  3. Mark A.
    September 1, 2009 at 12:48 pm | #3

    I see Singletons just like static variables. If I want to get an instance of my soundplayer (in a game) I either do it by using SoundMachine.getInstance() or by Application.soundmachine.

    Where is the big difference and how do you estimate the amount of work to do when NOT using static vars or singletons in a case like that. Pass-through the soundmachine until it reaches the nested objects where it is needed? … puh…

  4. aYo
    September 1, 2009 at 2:17 pm | #4

    I concur with you Mark. Irrespective of what people say there is a place for static/global variables. I really do not care what the purists say. Patterns are guidelines and not enforced practices. They should be modified as seen fit. I see no reason why I should endure a long process of iterating through nested objects or creating Mediators or facades where a Singleton or some such construct will suffice. As I have said earlier its all in the architecture of the application. Personally I do not use Singletons as a substitute for globals. They act as constructs for me that ensure that in changes of state certain aspects of a class are not recreated or reinstantiated – an extra bit of insurance as it were. Yes I can do that with out a SIngleton construct but I prefer to use it in this manner and I have had few problems. As for carrying state while the programme last I guess we will have to ban Shared objects since they also hold stateunder certain circumstances. Good practice, understanding and knowing where and when to apply are the key and not an outright condemnation of one structure or the other.

  5. Mark A.
    September 1, 2009 at 2:38 pm | #5

    I would really appreciate if someone could explain me the benefit if I pass along references to objects deeply. Then I also get coupling because a lot of methods will have a parameter typed to my class (again SoundMachine).

    Sure, you can say: Why not instanciate the Soundmachine where it is needed. But in a game you have so many places where you want sound to play..(menu, ingame, etc).

  6. Aaron W
    September 1, 2009 at 2:54 pm | #6

    I stopped using Singletons after I watched this talk by Misko Hevery:

  7. September 1, 2009 at 3:57 pm | #7

    Mark and aYo,

    You’re making the broken clock argument and suggesting I’m a purist. (I’m not the one genuflecting at the feet of St. Singleton!) As aYo knows, I can get as sloppy as the next guy in coding and go off on wild tangents.

    I’m really trying to get away from poor coding practices, and that’s why I listened to aYo when he first broached design patterns. (aYo has no one but himself to blame!) At the time I was working with Jonathan Kaye who had introduced me to State Machines and between Jonathan and aYo, it was clear that better coding solutions were available, but the problem was having to go through a whole new way of thinking about problem solving. Starting with statecharts, it was easy to focus on states (that I equated with situations.) Up until that time, I was focused on a journey–essentially a set of procedures to get from Point A to Point B, and even though OOP was nothing new to me, it never dawned on me that a new process to go with objects was as important as the objects themselves. That’s why I try to avoid problems in developing this better process, which includes avoiding the Singleton. To say that there are situations where the Singleton is okay, is like saying that a broken clock is right twice a day. You believe that you have found situations where they are valuable. That’s probably true, but in a context where the programming is in an environment where one object sends a message to another that does part of the process and then sends a new message off to another object for another task and so forth, why intentionally use a structure that can trip up that process?

    Getting this stuff right is like trying to climb a glass mountain. It’s steep and slippery; so it’s best to avoid known problem areas. That’s why I stay away from Singletons. I have nothing against them otherwise, and were I a purist, I’d never have listened to the Singlteon’s critics in the first place.


  8. Mark A.
    September 1, 2009 at 11:42 pm | #8

    Nicely said :) And I have to apologize if you found me blaming you. No way! I’m absolutely in the same position and I want to know a good practice for that kind of problem. Is it really better to pass through deeply?

  9. gropapa
    September 2, 2009 at 12:57 am | #9

    hi there, i don’t think the singleton is a bad pattern, it just depends the way you use it. For example, i started looking the pureMVC frameWork, i m still a beginner with it but as you must know it is built upon a interface, which is a singleton.
    Is this bad? well William you said the singleton “Promotes tight coupling” and that is true and in the case of the PureMVC framework, that is exactly the what they wanted to do!
    I think as long as the singleton is the “base” class used in a oprogram, it is not a big deal at all!
    But I still don’t understand why the View class is also a singleton but i will try to figure that out!

  10. September 2, 2009 at 1:16 am | #10

    Hi Mark,

    We’re all in the same boat trying to align our practices with good ones. To me, if we didn’t have these discussions, all of us would be poorer for it. If it weren’t for people like you and aYo who really use their minds and critically think about these issues in programming, we’d all just mire in whatever bad habits we had–especially me!

    Kindest regards,

  11. September 2, 2009 at 1:54 am | #11

    Hi Gropapa,

    First, it’s Bill not William (way too formal.) Second, unless I’m way out in left field, the singleton that Chandima speaks of in the PureMVC refers to a single instance and not a Singleton design pattern. A Facade design pattern is a good example of a singleton in the sense that there’s a single such class in a framework element or you have a single element. Compare the Singleton class in Chapter 3 and the ‘singleton’ (single instance) in the PureMVC. [I’ll ask Chandima to comment on this.]

    Oddly, if Singletons are “done wrong”, they may not work as intended and not cause as many problems as when they are correctly configured as Singletons. In other words, if you build them as global variables, you’ll have problems because your system can become unstable due to a global variable changing something in the system that is unexpected and unwanted. Miško Hevery’s talk on the problems with Singletons that Aaron mentions details the ways in which global variables can ruin your day. (By the way, if you do watch that video, the reference to JVM is to Java Virtual Machine — the talk is being given to a group of Java programmers.)

    As always, thank you for your insightful comments,
    Bill (not William!)

  12. September 2, 2009 at 2:05 am | #12


    Thank you for mentioning Miško Hevery’s video on the Singleton. I had read Miško’s articles, but I had not sat through a video. (Generally, I’m too antsy to sit still for a video—but not this one!)

    Miško’s step-by-step demonstration of the nature of the problems that Singletons cause is very helpful, and I think that it does an excellent job of pin-ponting the issues that I’ve tried to raise more generally.

    Kindest regards,

  13. Chandima Cumaranatunge
    September 2, 2009 at 5:41 am | #13

    Hi gropapa,

    The Model, View and Controller classes in the core package in the standard version of PureMVC are Singletons that serve as global registries. For example, the Model singleton holds a global map (array) of proxy instances. Once the PureMVC framework is initialized, this array persists through the lifetime of the application.

    The Facade is a Singleton as well and holds references to the Model, View and Controller singletons.

    Event though the API is lightweight and open, there is persistent global state that can be problematic from a testing standpoint because there is no way to initialize a new PureMVC framework before starting a new test.

    Of course you can remove all the proxies, views and models after each test case so that the next test starts off on a clean slate. However, there is no way to ensure that this is the case. For example, there is no way to inject an empty proxy map and re-initialize the framework.

    PureMVC multicore alleviated this issue somewhat. Because now, each test can instantiate a new PureMVC core. Even though the global registries still exist, as long as cores get garbage collected, and don’t persist from one test to another, testing should be OK (I think).

    Singletons, or any code for that matter, that encapsulates global state is bad from a testing standpoint. However, as Miško stated, you must trust the framework / lower-level APIs at some point. PureMVC is not broken because it implements Singletons – it is a mature framework. Incidentally, the ModelLocator in the Cairngorm framework is a singletons as well.

    If you follow the programming idioms recommended in the PureMVC docs things should be OK. But the framework does not explicitly prevent anyone from extending it to let global state creep in and disrupt the whole application.

    Miško Hevery has a detailed blog post on Singletons and Testing that has more code examples.

  14. lukas buenger
    September 2, 2009 at 5:46 am | #14

    Hi Bill,

    I’m reading your book at the moment and have read your post where you crusade against S.Singleton before I started reading the correspondent article in your book. Maybe I got it all the wrong way, thats why I’d like to comment on the points mentioned above. Correct me, if I’m misled to something:

    1. Acts like global variables
    Only if you use it that way. If that’s true, every static member (not method) is kind of global and should be decapitated for its possibly global behaviour.

    2. Violates the single responsibility rule
    Only if you implement more than one responsibility. It doesn’t prevent you from doing so, but even if S.Singleton is a mighty lad, that mighty it will never be.

    3. Promotes tight coupling
    Nah, why? As any other class you can interface it, hide its constructor behind a factory and so on. To me it seems like even the mentioning of Its name drives everybody crazy, so that one simply can’t but add a reference of a Singleton to every class in your whole project.

    4. Carries state as long as the program lasts
    Ok, that’s a point. Others do too. Whether you implement a single state carrier as Singleton or as a class that just happens to occur just once throughout your whole app doesn’t make no great difference to me.

    So my point is: S.Singleton can be damage the health of your app gravely, but so can any other pattern when used in the wrong way. It is difficult to anticipate a situation where a Singleton can be usefull but that doesn’t necessarily make it a no-go, does it?


  15. September 2, 2009 at 11:20 am | #15

    Mark A. & aYo:

    I hear your concerns, but be careful of discarding the advice of “purists”. There is a reason that people see the Singleton pattern as “evil”, and it’s unfair to simply call those people “purists”; they arrived at that conclusion after careful study, and you would do well to go on that journey for your own development. Understanding why Singletons are “evil” is a great way to improve your grasp of Object Orientated Programming.

    “I see no reason why I should endure a long process of iterating through nested objects” … “I would really appreciate if someone could explain me the benefit if I pass along references to objects deeply.”

    Indeed, that would be entirely the wrong solution – a lot of effort, a lot of coupling, and a violation of another principle: classes should never be passed objects that they don’t directly use. You should look into the Inversion Of Control pattern (otherwise known as Dependency Injection). Here’s a good post that should answer your immediate question:

    In fact, Misko’s blog is a fantastic resource, and every post is worth reading. Here is a good place to start:

    Yes, static methods and variables are evil too :)


    1+ for more arrows :)

  16. September 2, 2009 at 11:53 am | #16

    Hi Lukas,

    I hope I don’t sound like Carrie Nation wielding an ax on a crusade after Satan Singleton…. Rather, you have a design pattern that is documented as causing problems–the four above noted may be mitigated as you say, but why in the world would a major software company (Google) have a utility to detect and flag Singletons unless they posed a serious problem? Further, what happens if you drop Singletons like a bad habit? Nothing. Absolutely, nothing. The world is not held together by Singletons. Some are acting like the Singleton is a white powder that they have to shoot up their nose or they won’t make it through the day. It’s not. As one developer suggested; try doing without Singletons for a year.

    Another thought occurred to me. ActionScript does not have true private classes — it has no private accessor for the class structure. Maybe that’s why some ActionScript developers haven’t been hit up side the head with the problems described by Miško Hevery and others. It helps ActionScript 3.0 developers from shooting themselves in the foot. So the reason that Singletons have not been been a problem in Flash/Flex is that they cannot be done right. That is, the problems detected in Singletons is due to doing them right, and without a private class accessor, ActionScript 3.0 developers have not encountered these problems because they have never done them right.

    Thanks for your well thought-out comment. Chandima and I appreciate it, and the other readers do as well. We hope to hear more of your thoughts on these topics.

    Kindest regards,

  17. T
    September 2, 2009 at 6:04 pm | #17

    Wow, this post has been an eye-opener for me. The lecture from Miško Hevery was very useful, and he explained it very well.

    It does seem like eliminating Singletons altogether and requiring everything to be passed into constructors is the way to go for many reasons. It also seems as though it would create a bit more code in some cases. I believe I use Singletons most of the time when I am trying to reduce my lines of code, as opposed to truly making the code more modular.

  18. September 2, 2009 at 6:32 pm | #18

    Hi T,

    I think you hit a nail on the head that I didn’t think about—attempting to reduce code instead of making it more modular. I used to do the same thing; squeeze code like I was doing something right. It just seemed like a good idea, but in fact I was making the structure tighter, less adaptable, and more difficult to introduce change.

    Well, I finally realized that loosening up will not drain the earth of silicon. You’re right. Miško Hevery is a very savvy dude, and he’s right on target.

    Kindest regards,

  19. Hugo
    September 10, 2009 at 8:07 am | #19

    Hi Bill and hi everybody,

    Hierarchical State Machines and State Machine patterns use singletons ( states are singletons ), some aspect oriented design and separation of concern designs use singletons and aren’t that bad. What i want to say here is that singletons can and should be used if their use is appropriate, singletons are present in the Facade pattern and permit loose coupling. it all depends on the way you feel more confortable developing sometimes using a singleton is just great!

  20. September 10, 2009 at 12:41 pm | #20

    Hi Hugo,

    I believe that you’re mixing Singletons as a design pattern and singletons as a single class within a system or pattern. Just to help us communicate, the class is capitalized (Singleton), and the single class is not capitalized (singleton).

    Nothing I’ve said or other critics of the Singleton have said applies to singletons. So while each state implementation in a State design pattern is a singleton; none are Singletons.

    Good to hear from you and thanks for your comments,

  21. Hugo
    September 10, 2009 at 3:11 pm | #21

    Hi Bill, i know that singleton is the class and the pattern is Singleton but ok .. i didn-t explain myself correctly.
    by the way

    * The Abstract Factory, Builder, and Prototype patterns can use Singletons in their implementation.
    * Facade objects are often Singletons because only one Facade object is required.
    * State objects are often Singletons.
    * Singletons are often preferred to global variables because:
    o They don’t pollute the global namespace (or, in languages with namespaces, their containing namespace) with unnecessary variables.[7]
    o They permit lazy allocation and initialization, where global variables in many languages will always consume resources.

    this according to wikipedia.
    but as a personal experience using the Singleton Pattern if i use it at an higher level in my app it does permit loose coupling the problem with Actionscript like it was said before is that Actionscript doesn’t really have a correct way to implement it. There are hacks to it,Grant Skinner and others have largely blogged about it.

    The thing about the Singleton Pattern according to standards is that is makes the Application not to follow a principal like a class having a single responsability.

    Should a principle be a law ? does it mean i have to have just one responsability in a class

    the Singleton Pattern definition says:
    “Singleton is a class which permits itself to be instantiated only once. It…

    * has a private or protected constructor with no parameters.
    * has a single, global means of access via a static method.
    * cannot be subclassed nor instantiated with the new operator.
    * uses lazy instantiation.

    Singleton can be used—in fact, is required—in many situations, for example:

    * caches
    * device drivers
    * dialog boxes
    * loggers
    * thread pools

    so is it really that bad to use a Singleton ?

    furthermore i found an excellent entrie on the subject and yes it bashes the GOF Singleton Pattern but it also states that there are some places where the use of the Singleton should be made … at the top tier of your application and in loggers

  22. September 10, 2009 at 6:32 pm | #22

    Hi Hugo,

    First off, it’s dangerous to cite wikipedia–take a look at their “explanation” of a Private Class. Second, I didn’t mean to sound insulting in differentiating a singleton from a Singleton for you—some people really don’t know.

    In all of the examples you cite, you talk about the Singleton as a possible inclusion in those design patterns, but why? Because there’s only a single Facade class in a Facade design pattern does not make it a Singleton class. In fact, it behaves very differently from a Singleton. A Facade handles variation as an interface to a subsystem, while a Singleton handles variation as the sole instance of a class.

    If you added a Singleton to an Abstract Factory, it’s like putting a wart on the face of a beauty queen. Why would anyone do it? As for State objects being Singletons, I just don’t agree. It’s hard to imagine something as dynamic as a State implementation being a Singleton. In fact it gives me the creeps….

    In loggers I can see the purpose of a Singleton. But seeing a purpose does not mean it’s a good idea to add a possible global variable to your mix.

    However, this post (Saint Singleton: Have We Martyred a Design Pattern Unfairly?) was meant to encourage discussion, and with so many bright people on our blog, I should have expected more than a shrug from our readers.

    So get involved in our Golden Lunch Bucket Contest #4 and enter the Golden Lunch Bucket World Cup!

    Thanks for hanging in there.

    Kindest regards,

  23. mike
    September 14, 2009 at 10:18 am | #23

    So… I’m fairly new to Design Patterns (sorta). I am not new to AS3 though.

    Now maybe its because of the type of things I am asked to develop but I have to say I use a Global Singleton at the beginning of all my projects and bring it into most of my files. The stuff I develop is all highly graphical and elaborately designed websites for Movie Studios… Paramount, Fox, Universal ect…

    As much as I’d like to follow nice clean patterns all the time I just find it impossible sometimes. Here’s what I keep track of with my Global:

    XML Files (text, release dates, videos, photos, ect..)
    Initial SWF’s (Main, Home)
    — the above is contained in a BulkLoader —
    Reference to BulkLoader
    Reference to Main.swf

    Then throughout my Flash project I simply call up the xml file needed through my Global.vars.BulkLoader reference. I also keep my SoundController in my Main.swf so alot of times I talk back and forth with the Main.swf to trigger sounds, mute all sounds, turn them on.

    I just don’t see any real other way around certain things then keeping them Global across my project. I try to use my Main.swf as my Globally accesible control panel and keep one reference to my Main.swf in my Global Singleton so I can talk to it easily anywhere I need to. Which like I said could be SoundControllers, TextureLoaders, Global Site Pausers, Video Controllers that also react to SoundControllers.

    In my case I just don’t think there’s a better way to control multiple swf’s and multiple things going on at once without the use of at least my one Global Singleton.

  24. September 14, 2009 at 11:44 am | #24

    Hi Mike,

    Without knowing what your projects do and how they’re set up, it’s impossible to say where a Singleton may come up and bite you. I just don’t like the possibility of an IED in my code. Further, while you know of no other way to do what you’re doing, we both know that some bright light will come along with a better way that neither of us thought of. It may be with a design pattern or not, but most likely it will be an OOP solution.

    The issue has never been that Singletons don’t work. They do. The problems are more subtle and as you note, you don’t see the problem with global variables either. They have creepy characteristics that will get you sooner or later, and I avoid them because of that. However, you can do things with globals that you cannot do otherwise. The problem is that if a global can achieve a task that nothing else can, you’ve probably picked an non-OOP solution.

    I think a lot of us end up using non-DP solutions because it just takes too long to work out a dp solution, or you have a solution that has worked well without any problems and the time and effort to change are too great.

    As we muddle our way through all of this, we improve by nano-degrees, and all of us want better code. That’s why I brought up the limitations and problems with using Singletons.

    Ironically, at next month’s OOPSLA meetings I’ve been asked to deliver a presentation on where a non-OOP solutions works while an OOP solution doesn’t! (The author of the paper has to be away judging a Computer Science competition.)

    Here’s an idea. Let’s take some project you do and find a DP solution for it. It can be an old one (and something small!) so you won’t get into contract trouble. Then we can explore something practical and possibly come up with the kind of solution you’re seeking.

    Kindest regards,

  25. mike
    September 14, 2009 at 8:23 pm | #25

    While thats an amazingly generous offer I would find it almost impossible to choose which project I and everyone else could learn from the most. Especially when after each project I go and try to ‘better’ something I found to be an annoyance in a previous project.

    I guess my most common task would be a SoundController (which I could then relate to several other tasks). Here is a typical set up.

    Contains SoundController
    Loads Section SWF’s
    Plays Main MP3

    Loads Video or Photos or Downloads ect…
    Triggers several Sound FX and perhaps a new main MP3.

    I need all sounds in my website to be able to be turned off all at once from within my Main.SWF, triggered from several different Section.SWF files, and I also need them according to a variable be retained in memory so I don’t have to burden the server over and over for a sound file that is used more then once.

    Without wanting to pass references to a newly loaded SWF immediately upon loading it to be able to use the same SoundController. I know I could also use Getter/Setter but then I also need an easily obtainable reference to the Main.SWF which houses my SoundController. Would it not need to be a Singleton, otherwise it would not be able to be turned off Globally from 1 spot and also not use the same ‘memory’ table.

  26. September 15, 2009 at 2:54 am | #26

    Hi Mike,

    One of the problems I had to unlearn was tightening up my code–I had to loosen it up considerably. Also, I found it helpful to drop the name Main and use Client instead. (I did this simply because GoF uses Client as the name for the class that made requests from the classes in the design pattern.)

    For the time being, forget there’s anything like a global variable—in fact, let’s pretend they don’t exist. Also, for the sake of argument, we’ll also pretend that GoF never introduced the Singleton.

    So here we are with the key question, What varies? You want to turn music on and off; so, you can see that state varies. Further, you have a number of objects that depend on another object along with how the dependent objects stay up to date with all of the different videos and images. Another way of putting that is you have a situation where the State and Observer designs can be of help. With those two patterns, why not make a MVC? (Or a PureMVC?)

    For a long time now, I’ve wanted to create a relatively simple MVC for the Lunch Bucket series (design patterns you can take to work) and your kind of project sounds to be a perfect candidate—albeit a scaled down and simplified version. The goal would be to coordinate video play, photos, download and sounds. (This might suggest that we’re dealing with families of product objects that vary, and hence the Abstract Factory, but with the MVC there’s the ability to include more than a single design pattern.)

    The goal is to create a design that would be easy to update and changes don’t domino fall throughout your project. Does that sound about right? Send a URL that shows the end results, and I’ll put a just the basics MVC together to do the same thing. It will call on the following:

    1. Graphics (in SWF and graphic formats, I’m assuming)
    2. Video (progressive download or FMS?)
    3. Sound (MP3 files)
    4. Flash animations (in SWF files)

    Is that about right? I don’t want to know anything about your code or your current setup—just what you expect for an outcome and for maintenance.

    Kindest regards,

  27. Mark A.
    September 15, 2009 at 4:09 am | #27

    nice offer. looking forward to the result :)

  28. mike
    September 15, 2009 at 7:37 am | #28

    Here’s one. Its pretty simple and straightforward as well as being a fairly typical sequence.

    Loader > Intro > Main > Loader > Sections

    I think like I said one of the things I’m curious about is Global control and monitoring of actions that are taking place within sections… oh a Video is being played stop music, a link was clicked stop music and video. The other thing is passing of data between unrelated things. Main loads a master xml… knows to load a video for next section… plays next section… next section grabs xml from Main.

    I guess what I’ve been starting to see is that for components with in the site I can pick out a design pattern like for the video component, or wallpaper switcher, sound controller, photo swapper/enlarger. But then the piece I can’t see is how to then link all these together and be able to monitor them all in the Main/Client cleanly without sending arbitrary commands back and forth and always checking thing’s with if statements all over the place.

  29. Benjamin
    December 16, 2010 at 3:46 am | #29

    Hi William,

    Thanks for the post. I am designing a Resource Manager (RM) for as3. I want to have a system where I can easily convert xml language files and data files to as3 classes. And also the possibility to keep track of the current language. I won’t explain this system but I stole what I think are some good concepts from Microsoft’s DotNET (in which I program a lot) and started designed a system which works for me and helps me create flash apps faster, focussed on content management.

    At one point I was figuring out how to keep it globally accessible and not have to load the xml files in every class I use the RM. So the Singleton Pattern was the first thing that popped into my mind. I’ve read your book and wanted to review how to do the singleton in as3. Then I read the post here and some other posts and I think they have good arguments. I thought, what should I do if I can’t use the singleton? A simple factory might do the job I hear some people say.
    What do you think about this: client instantiates RMFactory. But keeps an interfaced reference like IRMFactory. This factory makes sure there is only 1 RM created. The factory itself will create the RM but keeps the reference interfaced like IRM. So at this point we have no tight coupling, got rid of the single responsibility violation (I haven’t done research on the other arguments yet). Also I can access the data and language objects in every class through the factory > RM.

    This is what I get from the reactions. I just want to make sure I’m thinking in the right direction. I didn’t explain what the RM is actually doing because with my question I want to focus on the Singleton problem. Sorry if I talked to much about the implementation, because the discussion is more of a ‘philosophical’ discussion.
    Regards Benjamin

  30. December 16, 2010 at 12:50 pm | #30


    I suppose you can talk about two kinds of singletons. One is simply an algorithm that insures that you only have a single instance of an object, and the other is Singleton design pattern.

    Using a RMFactory with a singleton method may solve the problem and not generate the kinds of problems a Singleton design pattern does.

    1. singleton algorithm (method): Ok
    2. Singleton (dp): Bad

    Kindest regards,

  1. No trackbacks yet.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>