Is this the solution to static inheritance?

Question

I've seen a lot of posts recently on why Singletons should be avoided. However, I can't see any of those problems with the following solution to a common problem: static inheritance.

For example, I was recently working on a library that scrapes the HTML source of a website and parses its contents into objects. The problem here is, the site has different types of content- articles, videos, etc. In my initial code, I had several different static 'supplier' classes- i.e. ArticleSupplier- that I quickly found shared a lot of boilerplate code (i.e. argument checks).

I could have made the classes instance-based, but it seems pointless: new ArticleSupplier() has no state; all its methods depend on the arguments passed to them. Instantiating another one is just a waste of memory.

This has brought me to thinking about using the Singleton pattern: a base class could perform boilerplate code checks and then call the derived class' implementation; the derived class could then control access with a singleton. Here's a simple example in C#:

abstract class Supplier
{
    IEnumerable<IModel> RecentModels(int amount)
    {
        return ModelsBefore(DateTime.Now, amount);
    }
    IEnumerable<IModel> ModelsBefore(DateTime date, int amount)
    {
        CheckDate(date);
        CheckAmount(amount);
        return InternalBefore(date, amount);
    }
    abstract IEnumerable<IModel> InternalBefore(DateTime date, int amount);
}

class ArticleSupplier
{
    private static readonly ArticleSupplier _Instance = new ArticleSupplier();
    private ArticleSupplier() { }
    public static ArticleSupplier Instance { get { return _Instance; } }
    override IEnumerable<IModel> InternalBefore(DateTime date, int amount)
    {
        // implementation
    }
}

Now, you can focus on the implementation within ArticleSupplier without writing the same boilerplate code, and at the same time control instantiation of the object. I'd like to emphasize again that this is completely thread-safe because the singleton has no state, which is why the method was static in the first place.

Is this an appropriate use of the Singleton pattern, or are there still some pitfalls that I'm missing?

Answer 1

Is this an appropriate use of the Singleton pattern, or are there still some pitfalls that I'm missing?

No, this has almost all of the pitfalls of singletons and even that assumes that you actually use Supplier almost everywhere and have other implementations. I'm not going to go into the various pitfalls of singletons as they have been covered well elsewhere.

Instantiating another one is just a waste of memory.

4 bytes. You are limiting your design for 4 bytes? Yes, it currently has no state. Yes it is currently threadsafe. It seems entirely plausible that a future version will need to parameterize the location of your articles, or perhaps some info about how the articles are sharded by creation time, or by any number of things. But you want to hamstring yourself because of 4 bytes?

The singleton is an antipattern. You are not going to change that.

Answer 2

What you are looking for is not a singleton, but a factory. The reason is you have a single object that figures out which logic to execute, then executes it. As you say in your comment, it is functionally similar to a switch statement: figure out which branch to execute, then execute it.

That works fine if your logic is simple, but once it grows in complexity, the switch or cascaded if grows cumbersome. Furthermore, you want the code to load implementations dynamically, not via compile-time selection. It is better to bury this logic in an object instead of one long method. I recommend the following components:

• Each "method" or algorithm, i.e. each "supplier" in your example, has a pair of classes:

  • An actual supplier that does whatever your problem needs it to do.

  • A service provider that determines if this particular supplier can handle the input, and is able to create the supplier.

• One class that represents input data for easy passing between methods (no overloading necessary).

• One factory class that accepts input and returns an object capable of processing it.

Example in pseudocode:

class Input {
  public DateRange range;
  public int quantity;
}

interface ServiceProvider {
  boolean canHandle(Input i);
  object newHandler(object o);
}

class Factory {
  List<ServiceProvider> sps = new ArrayList<>();

  public static void register(ServiceProvider sp) {
    sps.add(sp);
  }

  public static Supplier getSupplier(Input i) {
    for (ServiceProvider sp in sps) {
      if (sp.canHandle(i)) {
        return sp.newHandler(i);
      }
    }
    return null;
  }
}

Notes:

• This replaces switch with dynamic dispatch via traversing the list and finding an instance that can handle the input.

• This is a simple example to give you the idea. Depending on the specific problem at hand, it may be better to use a hash table or other data structure.

• Service providers need to register themselves. The specific mechanism to do this is dependent on the language (your question is not tagged with a specific language).

  • Java can use the Service Provider Interface.

  • C++, static linking: just call an initialization function to set this up before use.

  • C++, dynamic linking: set it up in DllMain or the equivalent entry point for your platform.

  • C#: you can implement the IServiceProvider interface.