Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I wrote a standalone singleton class (scaffold) tonight that serves as a facade to a few other classes, including a template class and a view class. Templates and views are both named and instances of each are stored in the scaffold object. Templates can contain views and views can contain other views. A template and it's contained views is rendered when:


Making scaffold a Singleton seemed like a good idea because:

  • I want to control when and how the object is constructed
  • I only want one instance (the gui will only be rendered once, regardless of the template which is rendered)
  • All state can easily be released from the scaffold class (if, for testing reasons or whatever, I wanted to)

Does this seem like an acceptable use case? If not, what specific design considerations am I overlooking?

No religious wars, please. I didn't include the language because I'm hoping for a language agnostic consideration, but I will say:

  • Scripting language
  • Single threaded
share|improve this question
What state will the scaffold have? This sounds more like a case for a static method than for a singleton. – Carson63000 Aug 1 '12 at 11:03
"I want to control when and how the object is constructed". If you're going to use a singleton, you give up control over this! – vaughandroid Aug 1 '12 at 11:17

There are hardly any circimstances under which a singleton is legitimate (the only one that springs to mind is providing an interface to a hardware device or register which needs to be shared but for which it would be catastrophic if each program that accesses the resource did so at the same time). Singletons introduce far more difficulties than they do benefits, they are essentially global state and they create hidden dependencies, all of which makes unit testing far more difficult than it would be if you passed the dependencies in as parameters

share|improve this answer

The unique thing about Singletons is that you enforce that there can only be one instance at any given time. Singletons are somewhat appropriate when you have to enforce this; if being one-of-a-kind is convenient, but not absolutely required, you don't need a Singleton.

There is no reason to hide the constructor: just make it publicly accessible, and provide a static method to get the global 'default' instance. Most of your codebase will use that, it's accessible from anywhere (which isn't necessarily a good thing; you're trading safety for convenience), but if you decide that at some particular point you need a dedicated instance (e.g. for testing, or because the template engine carries some state that you need to mess with without affecting other parts of the codebase), you are free to create one.

share|improve this answer
This makes sense = ) – Calvin Froedge Aug 1 '12 at 16:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.