Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

GenericFactory as Singleton

I read the article Abstract Factory, Template Style by Jim Hyslop and Herb Sutter. This factory is implemented as a Singleton. They provided an easy way to register classes automatically with the RegisterInFactory helper class.

Now i've read several times that Singletons should be avoided, some even consider them as Anti-Patterns and that there are just a few cases where they are usefull. Is this one of them? Or is there an alternative approach which provides such an easy way to autoregister classes?

like image 541
P3trus Avatar asked Jan 19 '11 09:01

P3trus


People also ask

Can a factory be a singleton?

I've a lot of (abstract) factories and they're usually implemented as singletons. Usually for the convenience of not having to pass them through layers who really have no business with using or knowing these factories.

What is generic Singleton?

The Generic Singleton Pattern in C#The generic constraint 'new()' on the type parameter means that the class T will have to provide a public parameterless constructor. This means that any client code will be able to create as many instances of class T as it likes. Thus, this breaks the Singleton pattern.

What is the difference between Singleton design pattern and factory design pattern?

The Singleton pattern ensures that only one instance of the class exists and typically provides a well-known, i.e., global point for accessing it. The Factory pattern defines an interface for creating objects (no limitation on how many) and usually abstracts the control of which class to instantiate.

What is singleton factory and builder design pattern?

Singleton – Ensures that at most only one instance of an object exists throughout application. Factory Method – Creates objects of several related classes without specifying the exact object to be created. Abstract Factory – Creates families of related dependent objects.


1 Answers

As ever for this sort of subject, there is no answer that applies to every problems. Some said that singleton should be avoided when they are used as an access to a service. It is a use that is akin to the use of global variables. This way you mask the fact that you use service X in your implementation :

// in header
class MyUsefulClass
{
    public:
    void doSomethingUseful();
};

// in .cpp
MyUsefulClass::doSomethingUseful()
{
    // ...
    MyWonderfulService::instance().doService1();
    // ...
    MyWonderfulService::instance().doService2();
}

You create a coupling with MyWonderfulService that the users of your class can not guess. Moreover, You can not easily test your useful class with a mock service ...

That's why I usually prefer dependancy inversion :

// in header
class MyUsefulClass
{
    public:
    void setServiceToUse(MyService&);
    void doSomethingUseful();

    // [...]
};

// in .cpp
MyUsefulClass::doSomethingUseful()
{
    // ...
    _myService->doService1();
    // ...
    _myService->doService2();
}

This way is usually considered better as the coupling between class is lighter. Nevertheless, for some services, which are well known to be of widespread use in a framework, it is simplier to use a singleton. It makes sense for a single service that is the service which give you access to all other services in a framework for example ^^ It is often use for technical services like logging for instance.

my2c

Edit: I read the article, as the focus is on AbstractFactories, the use of a singleton is a casual one, not a design decision. It is understandable in an article in which you do not want to write things that will not get you to your point.

like image 133
neuro Avatar answered Oct 09 '22 21:10

neuro