Sunt Lacrimae Rerum

In the nearly thirty years since Design Patterns came out, the Singleton has generally been recognized as an anti-pattern, encouraging the use of global data with a mask on and hiding the flow of control, to say nothing of complicating unit tests.

However, in the context of trying to convert legacy code into well-designed and tested code, the Singleton has a role to play as a Band-Aid (sticking plaster to right-pondians) as a temporary measure, even though its ultimate fate will be un-Singletoning itself.

Consider the case where we are converting a legacy method with some associated data into a proper class. It uses ambient data from the huge source file it is being pulled out of freely, but the data it uses is tightly coupled in a logical sense, and if you group it together it naturally attracts a few existing functions which use that data and little else, to make a nicely encapsulated class. The data tracks state of ene sort or another and notionally has to be unique.

// in file RecordTracker.h
class Record;

class RecordTracker
{
public:
    void addRecord(const TransactionId& inId, const Record& inNewRecord);

    const Record& getRecord(const TransactionId& inId) const;
};

// In file f.cpp
RecordTracker theRecordTracker;

class RecordUser
{
public:
   void processTransactionUpdate(const Transaction& inTransaction)
   {
       //...
       const Record& rec = theRecordTracker.getRecord(inTransaction.getId();
       //...
   }
};

The data is used in several other compilation units, where it was declared extern. We update all of those locations to use the new class.

Now our legacy method uses one object, which it is still reading from global data. If we extract an interface from the new object, we can pass it in to the object we are now building on construction, as an instance of simple dependency injection. So we do that.

// in file IRecordTracker.h
class Record;

class IRecordTracker
{
public:

    virtual ~IRecordTracker();
    
    virtual void addRecord(const TransactionId& inId, const Record& inNewRecord) = 0;

    virtual const Record& getRecord(const TransactionId& inId) const; = 0;
};

// in file RecordTracker.h
#include "IRecordTracker.h"

class RecordTracker: public IRecordTracker
{
public:

    virtual ~RecordTracker();
    
    virtual void addRecord(const TransactionId& inId, const Record& inNewRecord);

    virtual const Record& getRecord(const TransactionId& inId) const;
};

// in file RecordUser.h
class RecordUser
{
public:

   RecordUser(const IRecordTracker& inTracker): m_tracker(inTracker) { }

   void processTransaction(const Transaction& inTransaction)
   {
       //...
       const Record& rec = m_tracker.getRecord(inTransaction.getId();
       //...
   }
private:
   const IRecordTracker& m_tracker;
};

There is a remaining problem: the object in question is still global data, used in multiple places. In fact, the second class we extracted the function into turns out to be useful in some (but not all) of those cases, so it's getting the value passed in there via interface as well.

The original location might be tolerable - the data is static lifetime data in that place. It could even in theory be moved into the compilation unit for the second class as an implementation detail - but we still have all the other access points to look at.

Some of those access points have very long call chains before they go back to a common source, frequently main(), with narrow interfaces[1]. Many of them have little to do with the area we're working on aside from incidental use of the data in question, and it's not in our scope to do far-flung imperial refactoring beyond the area we're having to touch. So we have two options:

1. Leave it as it is; at least the class we're worried about is now functioning in a testable manner.
2. Convert the instance of the data into a Singleton and have all the places which currently use the concrete class use the Singleton Instance() method. (Don't actually change the data class: implement the Singleton to use the interface and delegate operations to the original substantive class. This doesn't mess with our testing and prepares for the end of the process when the Singleton goes away.)

#include "RecordTracker.h"

class SingletonRecordTracker: public IRecordTracker
{
public:

    static IRecordTracker& Instance();
    
    virtual ~SingletonRecordTracker();
    
    virtual void addRecord(const TransactionId& inId, const Record& inNewRecord)
    {
        m_delegate.addRecord(inId, inNewRecord);
    }

    virtual const Record& getRecord(const TransactionId& inId) const
    {
        return m_delegate.getRecord(inId);
    }

private:
   SingletonRecordTracker();
   RecordTracker m_delegate;
};

If we do the second, we have a clear marker for the issue. We can also push the actual invocation up our call stack for the immediate case we're dealing with, widening interfaces to accept the interface, until we get to the point where the instance "naturally" lives (frequently in main() if it's dependent in any way on program parameters).

In the future, refactorings can push up the calling level from other locations using the interface higher up the call tree. As we go, we may (probably will) end up with more classes which hold a reference to the interface, as well. Eventually, all the calls invoking the Singleton will be in the same context.

At that point, we get rid of the Singleton and replace it with a simple instance of the class. (If the program is resolutely single-threaded, it may even be possible to allocate it on the stack; otherwise it will have to be static or allocated via operator new.)

So the Singleton acts as a temporary way of patching the problem for a period of time, better than the original state, and also as a marker that the problem continues to exist. (The analogy here is not flesh-coloured or clear Band-Aids, but the ones with pictures of Dora the Explorer I used to get for my daughter.) The existence of those Instance() calls is an explicit and deliberate marker of what has to be fixed, and where.

[1]One application I know, originally C but mixed C/C++ for over 20 years, heavily used, passes all execution of transactions through a single function which takes one argument - an enum indicating the type of operation to take.  This logic is in shared code and is called in several different applications. Someday this will presumably be refactored, but until then it's a barrier to any attempts to get rid of global data in some form.

1. Observed as a headline on Google News: "I Was Rejected After a Manager Looked at my LinkedIn Profile" - unlike many other things online, your LinkedIn profile is entirely under your own control. It does not track history. It is meant to be for selling yourself. If you post things which might drive off potential employers, it's your own fault.

2. A CBC article on the movie "The Green Knight" does not inspire confidence in the research skills of its author when, after a reasonable amount about the poem at second hand (interviews with academics) it references The Lord of The Rings in its last paragraph without noting that the standard edition of the poem is co-edited by Tolkien and that he did a translation of the poem into modern English.

3. Multiple stories (notably from Alberta and Ontario, but also refracted from other locations) suggest that politicians (and some people) are focussed with tunnel vision on "returning to normal" (Alberta in general, schools in Ontario). They seem not to have realized that there will be no return, but rather the establishment of a new normal; or, more likely, they are in active denial. (One way of illustrating this is to look at the UK, where opening discotheques became legal a few weeks ago but where the venues are floundering in uprofitability because not enough people are coming out to them. The fact that something becomes legal does not necessarily mean that enough people will start to behave as though it is 2019 for a "return to normal".) I attribute this in part to bias (governments which are conservative/mammonite will be less likely to accept change constraining economic activity), partly to geography (conservative governments have a disproportionate number of rural members, who overwhelmingly want to see the end of restrictions of any sort), and partly to a general propensity for governments of any stripe to want to push a "good news" narrative even when it means getting out in front of the facts.

(Masks are not going away for many people, even if others enthusiastically ditch them. I expect heavy vaccine mandates in the private sector, both for employees and (in places such as indoor restaurants, gyms, and the like) customers. I expect the profitability of running a cinema to become very iffy. I expect workplaces where coming in to work while sick in any way becomes a major social blunder and possible disciplinary issue rather than a signal of dedication to the job. I am sure there are consequences I do not foresee; the current labour market suggests other changes.)

Ironically, this page had an ad put in immediately below it for "Wealthsimple: buy and sell stocks". Google's AI has a long way to go at determining the context of the links it put in...