C++ – Is there something like a polymorphic Singleton

Architecturecdesign-patternssingleton

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?

Best Answer

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.

Related Solutions

C++ Design Patterns – Difference Between Singleton and auto_ptr/unique_ptr

If you want to enforce that there is only a single instance of some class, then you must use the Singleton pattern. (aside from the question if your analysis is correct that you will only ever need a single instance.)

The C++ smart pointers auto_ptr<> and unique_ptr<> enforce a completely different contract, namely that there is only one reference (or pointer) to a given instance.

For example, this code is perfectly legal, but there are clearly two instances of Resource:

class Resource {
// ...
};

std::unique_ptr<Resource> instance1(new Resource());
std::unique_ptr<Resource> instance2(new Resource());

PHP Design Patterns – Single Class with Multiple Purposes vs Multiple Extended Classes

I think you are touching two often discussed topics here:

Monolithic classes vs small components
Composition vs inheritance

The following is a conclusion from what I've read and learned when I had similar problems to solve.

Monolithic vs components

Usually you should go for components that provide a model of the reality instead of building big monolithic blocks. Small components are easier to test and debug and harder to break.

Composition vs Inheritance

If you can go without inheritance you should. In your case the only common piece of File and Directory is that it has a path. Note the HAS A relation here. In fact the path is a property. Neither a directory nor a file is a path.

So - what you should go for is composition instead of inheritance. Please see http://en.wikipedia.org/wiki/Composition_over_inheritance for an introduction.

How to hold things together

Look for the factory pattern for returning a file or a directory depending on the type of file system object
Use an interface to define methods that both File and Path need to implement.
If both need the same functionality define a class for it. Usually the methods in this class are static. A trivial example would be a class FilesystemPermission that provides a method ::show($file_or_directory_object)

By the way - reading 'The Pragmatic Programmer' (look it up in the bookstore of your choice) covers such problems in depth - go for it if you haven't read it yet (every programmer should!).

Best Answer

Related Solutions

C++ Design Patterns – Difference Between Singleton and auto_ptr/unique_ptr

PHP Design Patterns – Single Class with Multiple Purposes vs Multiple Extended Classes

Related Topic