How can you replace the singleton pattern functionally?

Functional programming is a style of programming where you focus on what to solve rather than how to solve it. Instead of changing data and variables step-by-step (like making a recipe), you use functions that take in inputs and give outputs without any side-effects (like using a calculator). This makes the code more predictable and easier to understand. Think of FP as using functions to transform data, rather than manipulating data directly.

Use dependency injection framework. Singleton in fact is component with "application" scope. For Java it is Spring or Quarkus. Basically every modern language has several DI frameworks. So in normal, not a corner case code you do need singleton.

Having worked on projects where singletons are abundant, I can say this is the worst design pattern that came out of the original "Design Patterns" book. It should be considered an anti-pattern and never used in new projects. It is essentially a glorified global variable, and has all the same problems that come with global variables, which essentially all boils down to shared state. The biggest problem I've seen is test-ability. If the singleton is unit tested (which obviously it should be), then the state has been changed for all other unit tests, so the state must be "reset" to make it clean for other tests. If the state is not reset, it can lead to bugs in the testing code that is extremely difficult to find.

'Singletons' can be tested if you're using Dependency Injection to register a normal class as a Singleton. The dependencies, like a database or network service should be injectable as an Interface and then mocked in the test during construction of the class under test with known values that will then reset for each test. This Singleton class can be recreated in every test, so each test is 100% independent.

The Singleton Pattern can be problematic due to its introduction of global state, making code tightly coupled and harder to test. It often violates the Single Responsibility Principle, lacks flexibility, and can lead to concurrency issues in multithreaded environments. Additionally, Singleton promotes global access and hidden dependencies, making code harder to maintain and refactor. It's important to carefully consider the need for a Singleton in a given context, as its drawbacks may outweigh its benefits.

The singleton pattern is problematic for most people because they are wondering why they would write the singleton pattern if there isn’t some file that goes along with the singleton pattern because they want to link it to data or they think it’s some sort of global data they’re looking at somehow. In reality, it isn’t hard to test for a correct implementation of a singleton pattern and any context and if you know anything about security, ensuring that only one instance of an application is run or one instance of a window is opened is something important to know how to do so, even though it is problematic for some people to think about it is very important to learn .

Singleton pattern introduces global state, making it difficult to test, prone to hidden dependencies, and challenging to manage in concurrent applications.

To replace the Singleton pattern in a functional way, instead of having one shared item everyone uses, you can give each part of your program its own copy of what it needs. This way, every part only knows about its own piece, making things simpler and clearer. Think of it like lending books from a library. Instead of everyone sharing one book, each person gets their own copy to use.

The strategy here is to think contextually about where the class fits into the architecture of the OS other software, and everything else to make sure that it’s only being instantiated once anywhere otherwise, you are not really functionally replacing a singleton pattern. The singleton pattern can be applied to an application, an API or anything software related. The fact of the matter is any time something is duplicated, even though it might be duplicated in a context where you don’t think it is a singleton, it is not a singleton pattern. Being careful about the extent of the singleton “ness” is what is important and you can be neurotic about that because there are so many factors when a singleton pattern is replaced.

Functional programming is certainly beneficial and has many uses, but it does not solve the "problem" of shared/global state. Applications, more often than not, require shared state across many components. However, it does not mean the singleton pattern must be used, nor does it mean functional programming must be used. I'm not sure it makes sense to say that functional programming is a replacement for the singleton pattern. At least I cannot make this leap from reading this article. Perhaps someone else can chime in with an example.

Most of the benefits of already been realized because the static files instead of classes in old API library versions have been replaced so you can’t run into the pitfalls of having static singleton classes with data, and now that really makes the static singleton classes not really static or singleton but instantiated.