I have a resource loader object that loads objects from the disk or from a ZIP archive, depending on the platform.

It has state (e.g. the path to the directory or the ZIP archive, and possibly some caching in the future), so it needs to be a single instance.

So normally, a Singleton would do. But my problem is that this resource loader has multiple implementations, of which one is chosen at initialisation. So turning the resource loader into a Singleton won't do.

All I can think of is to have a Singleton that holds a reference to the single resource loader. But isn't there a nicer pattern for this?

  • 1
    have the getInstance decide which implementation it initiates instead of a single one – ratchet freak Jan 19 '13 at 17:59
  • I don't know c/c++ well so maybe this wouldn't be as easy to implement but in JS that sounds like a job for a singleton-factory pattern. The factory function decides what object to build and returns it or just returns the existing object as needed. I find it makes reorganization of code easier since you don't have to worry about what's in place when you have objects in play that shouldn't be copied but I could see how it might also solve your problem. – Erik Reppen Jan 19 '13 at 18:18
  • 3
    Why would it have to be a singleton? Non-singleton objects can have state just fine. – user7043 Jan 19 '13 at 18:33
  • 3
    Better to just not have a Singleton, ever. – DeadMG Jan 20 '13 at 14:55
  • 1
    You don't need to use the Singleton pattern to have a single instance with a state. – Spoike Jan 21 '13 at 10:28

What you want sounds like a good case for the Factory pattern. You would write something like:

class LoaderFactory {
  public Loader getLoader() {
    if (environment1) return ZipLoader.getInstance();
    else if (environment2) return DiskLoader.getInstance();
    else return SomeOtherLoader.getInstance();

Each type of Loader class is a singleton, and each should implement the Loader interface. Your LoaderFactory performs the logic that determines which type is appropriate to return.

  • Is it still the GOF factory pattern if a single method decides what to instantiate? – futlib Jan 23 '13 at 4:16
  • 1
    @futlib Why wouldn't it be? – user7007 Jan 24 '13 at 14:55
  • 1
    @futlib why would it matter if it isn't? – user40980 Jan 24 '13 at 17:23
  • 1
    Ironically, if you search Wikipedia for "Factory pattern" you will be redirected to Factory (object-oriented programming), and not to Factory method pattern as your link links to; apparently these are two different things. A bit confusing I might say. – HelloGoodbye Dec 15 '15 at 14:56

This have nothing to do with Singleton pattern.

What you need is some kind of resource manager type that would register factories objects, one for each resource type you want it to be able to provide. Each factory object would know how to load the associated resource type.

Then when you want a resource, you use a function to get the resource from a resource manager instance, that will find the the resource already loaded for you or will request the resource-type-specific factory it owns to load it.

It's interface would look like this (but it really depends on your context in the end):

class ResourceManager

    void add_factory( std::shared_ptr<ResourceFactory<ResourceType>> factory );

    std::shared_ptr<ResourceType> get(); // will look into registered factories and provide a resource instance if it   


This is classical way to manage resources gathered in an object.

Once you have such type (a ResourceManager class for example) working, it's easy to make it (or not, as others will suggest) Singleton. I don't recommend it though.

It's not your class that is polymorphic, it's the resource type.

A better way, most of the time, would be to pass a reference to the resource manager instance into functions and types that need it. There are cases where making it a singleton would be better, but it's very rare.

  • As I explained, it's not a singleton if you don't make it one. You could have several different resource manager instances if it makes sense for you specific case. Making it singleton is totally another matter. – Klaim Jan 20 '13 at 20:57
  • @LokiAstari I forgot to mention yesterday that I changed the formulation to clarify. Is it better now? – Klaim Jan 22 '13 at 17:56

All the answers are well stated. I just want to impress that polymorphism and singleton are what you might call orthogonal concerns. Polymorphism is more of a concept and how we achieve that concept, while Singleton is defining a pattern and taking advantage of the concept of polymorphism for use cases such as the one you bring up.

  • Did you mean "orthogonal" instead of "cross-cutting"? – Klaim Jan 20 '13 at 0:24
  • Singletons are by definition not polymorphic. – Spoike Jan 21 '13 at 10:33

Sounds like you have a use case for an Inversion of Control (IoC) Container -- they use what's called Dependency Injection (DI) to create/initialize instances of objects and wire things together for operation.

(This article about IoC Containers and DI might not be the best intro to IoC Containers (I can't seem to find a good one at the moment), but it's a good read.)

From what I've read they're similar to Factories and are good for instantiating things at run-time.

An SO post that might be of interest: Dependency Injection vs Factory Pattern

I'm not sure how this would work with getting only a single instance -- I've not used one before, only read about them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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