“The worst part of this whole topic is that the people who hate singletons rarely give concrete suggestions for what to use instead.”
In this talk, we will explore just such an approach for replacing the singleton.
It is easy to slip into the pattern of creating singletons - particularly in large legacy code bases - where low level functions need to propagate side effects - database updates, IPC etc. Passing parameters down long function call chains can be daunting in terms of scope of change required. Additionally, users calling a long established API in legacy code are frequently unwilling to change their calls to supplement the current data being passed in.
After reviewing a classic singleton approach to a typical problem ñ sending requests to a server ñ and it associated drawbacks.
We will rework the example by replacing the internal calls to the singleton with calls to an explicitly passed in wrapper class. The extra information required for production use is injected via a custom default instance of the wrapper. This wrapper can now be mocked out which allows for unit testing of the users calling code.
This alternative approach has been successfully employed in multiple areas in Bloomberg where developers believed there was no other feasible choice.