Should I use a singleton to represent the application as a whole?

Question

I make sure when designing software/firmware to make heavy use of dependency injection so that different pieces of the application are not directly coupled to one another. This also allows me to (potentially) unit test each piece of code using mock dependencies.

However, the dependencies that need to be passed into constructors need to be created somewhere. In other words, the application has to start from nothing at a single point (i.e., main).

I am wondering, is it good practice to represent the application as a whole as a singleton?

class IApplication
{
public:
    virtual int run(int argc, char* argv[]) = 0;
};

class Application
{
public:
    static IApplication& instance();
};

To be used like so:

int main(int argc, char* argv[])
{
    return Application::instance().run(argc, argv);
}

The implementation of the Application class then is in charge of constructing all the root dependencies and those objects which depend on them.

If this is not a good way to start an application, please explain why and provide a better alternative.

---

Based upon the very helpful answers so far, I thought it would be useful to add some more context. I develop firmware for embedded systems. I can write my application code so that it is abstracted (e.g., via dependency injection and abstract interfaces) from the hardware (i.e., register and memory-mapped addresses). However, at some point, I need to directly access those peripherals to get the abstract drivers to be injected. Those peripherals are at specific addresses in memory that are accessed globally (i.e., they are "singletons"). I would probably write Application to access these global hardware "objects" directly. However, if I do that, creating 2 instances of Application would be incorrect (they both directly access the same hardware), thus I was thinking, Application should only have a single instance and thus be a singleton.

I could get extremely abstract like so:

Platform myPlatform(Processor::instance());
Appplication myApplication(platform);

Where the application runs on any "Platform" (probably an interface) and the Platform runs on a specific processor/hardware of which there is a single instance (i.e., the one executing the code); but this will get a bit inefficient.

Answer 1

TLDR: singleton is about visibility as much as about lifetime.

Not for this context

There is no reason to use a singleton in this context. The application class does not expose any readable state so other components have no need to access it.

Not after fixes

The singleton pattern allows access to shared interface to any component of the program, and therefore can't expose any powerful methods controlling lifetime of the whole application or changing fundamental configuration.

Even if your example had a state - the state would be ill defined, as in the sample you provide, any component of your program can call run() method replacing and corrupting the global state.

If you fix the issue by adding protections to or around run() method, you will lose consistency of its behavior as there would be no guarantee whether any particular call of run method is a first one and which set of arguments is actual and in use.

Hypothetically, you could remove run() method from the public interface and leave only const methods available. But then you just get yet another unprotected, untestable interdependency between your components, which are no better than any other read-only mutable singleton. The problem of shared mutable state persists.

Solution

Do not use Singleton pattern. Do not use shared mutable state in general. Create an Application class instance in the program entrypoint.

Answer 2

From what you have written about the responsibilities of the shows classes, I think you mixed up the Singleton pattern with the Factory Method pattern (not to be confused with "Abstract Factory"). Your Application class could be just a factory for Application objects and hence should be named ApplicationFactory (instance could be renamed to create). The one IApplication instance can be provided as a reference to a single instance or simply as copy, it is unlikely that it will matter.

Whether you really need an interface/virtual base class IApplication with potentially different implementations (or not) is unclear from your question, so let me assume you don't need it and it can be renamed Application with a non-virtual run method.

This leads to:

class Application
{
public:
    int run(int argc, char* argv[]);
};

class ApplicationFactory
{
public:
     // some complex code to create an "Application" object,
     // maybe complex enough to justify an own class
     static Application create();
};

to be used like this:

int main(int argc, char* argv[])
{
    return ApplicationFactory::create().run(argc, argv);
}

This is structurally almost identical to your original approach, but makes a lot more sense to me.

In case you really need global access to the one Application instance throughout your program (for which your question gives actually no indication), then you can make this also Singleton, of course. For this, add a static instance method to my version of Application, make create a private method of Application and use it there.

class Application
{
    Application create();

public:
    static Application &instance();  // uses create on first invocation

    int run(int argc, char* argv[]);
};

int main(int argc, char* argv[])
{
    return Application::instance().run(argc, argv);
}

I removed the factory class here, and made the factory method create a private method of Application, because this will allow more effective prevention against the creation of multiple Application instances . If you don't need that prevention, you can still let create be part of its own ApplicationFactory class.

Answer 3

Though answers overall wanted you to avoid the Singleton, I have some points.

You have a container, for all those global static things. You want a dependency injection container.

As you make distinction between the application in production/development and the unit testing of the application, you might want to inject different things like mocks for the unit testing. Or development.

There is also the external configuration side. For instance for the multi-document interface, where one server application starts and for instance opens document X. Now a document Y is opened by another instance of the application. It looks whether there is already a (server) instance running an sends "open Y" to that server, then quits. Here is it more a matter of ports, entirely separated inaccessible Application objects. But you want to have an externalized configuration for this "server."

In both cases a dependency injection container seems just fine. However letting the application holding that container is not reversal of control. Take care of real dependency injection, instead of holding global objects like for internationalisation.

My advice is to immediately start with three scenarios at the same time:

• unit testing for test driven development;
• development product for the prototype;
• staging product to show the tester or product owner.

So my point: container == Application is not that weird. But behold specific customisation of globals. By the way, the java Spring framework uses an applicationContext as injection container.

(I have practical successful project experience, but might not be the best advisor on architecture.)

Answer 4

There is never a good reason to use a singleton. A singleton is just a global that involves more code (i.e., more places for bugs to hide). The only reason people use singletons is because they want shared mutable state, are aware of the taboo against globals, and don't understand the reason for it.

If you have shared mutable state, ask yourself if you really need it. If the answer is yes, then just use a global and be done with it. The thing that makes globals reasonably safe is carefully documenting what functions use them and how, not introducing a bunch of unnecessary design pattern cruft.