Singleton Pattern and Global Variables

Laura Ruiz

Hello community,

I have a question after reading a book on design patterns and researching online. I'm curious about why using the singleton pattern is often discouraged. I'm dealing with a scenario where I receive a request, and within that request, there's a specific form type, for example, Form-type1-virginia. The logic that needs to be executed corresponds to that particular state and form type, specifically type1.

I'm considering setting a global instance and accessing it to determine which validations should be executed. Is this a good solution? If not, what would be a better approach, or in which cases would you recommend using this design pattern or alternatively global variables? I would appreciate hearing your opinions on this.

Thanks.

Below is a snippet of the code I'm considering:

public class FormType
{
    private static FormType _instance;

    private string _type;
    private string _state;

    private FormType(string type, string state)
    {
        _type = type;
        _state = state;
    }

    public static FormType GetInstance(string type, string state)
    {
        if (_instance == null || (_instance._type != type || _instance._state != state))
        {
            _instance = new FormType(type, state);
        }
        return _instance;
    }

    public string Type => _type;
    public string State => _state;
}

2 Replies

Know the answer? Post it — somebody with the same question will find it here.

Mariusz Postol2y ago
Accepted answer
Naimish Makwana, from your explanation, it seems that singleton can be used for highly educated software designers, who can manage unexpected behavior, handle singleton as a common resource by concurrent threads, and solve difficulties related to unit tests. Shortly it means that the problem is related to the education of software designers but not to singleton design pattern itself. Is there any alternative? For example, for the same reasons the goto instruction was banned, but the alternative is structural programming including but not limited to "throw" instructions for me! Again, is there any alternative in case we need to guarantee the instantiation of a single object because we need a reference according to the object-oriented programming.? We can use static classes instead of singleton, but, my point is, that static class is rather an organization unit rather because we cannot create a reference to it. Arguing that something is difficult, prone to errors, and hard to manage there many concepts should be banned, like distributed programming, concurrent programming, database access, and many others, isn't it?
Naimish Makwana2y ago
The Singleton pattern is often discouraged due to the following reasons:
1. Global State: Singleton represents a global state which can lead to unexpected behavior and bugs that are hard to track down. It can also make the code tightly coupled and less modular.
2. Multithreading Issues: In a multithreaded environment, ensuring that only one instance of the singleton class is created can be challenging.
3. Unit Testing: Singletons can make unit testing difficult because they carry state for the lifetime of the application. This can create problems like tests having to be ordered, which is a bad practice.
In your scenario, you’re dealing with different form types and states. Instead of using a Singleton, consider using the Factory Pattern or the Strategy Pattern.

The Factory Pattern is a creational pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created. This could be a good fit because you’re dealing with different form types and states.

The Strategy Pattern is a behavioral design pattern that turns a set of behaviors into objects and makes them interchangeable inside the original context object. This could be a good fit because you have different validation logic for different form types and states.

Here’s a simple example of how you might implement the Factory Pattern:
```
public abstract class FormType
{
    public string Type { get; protected set; }
    public string State { get; protected set; }

    // Define your validation logic here
    public abstract void Validate();
}

public class FormType1Virginia : FormType
{
    public FormType1Virginia()
    {
        Type = "type1";
        State = "virginia";
    }

    public override void Validate()
    {
        // Implement validation logic for FormType1Virginia
    }
}

public class FormTypeFactory
{
    public static FormType CreateFormType(string type, string state)
    {
        if (type == "type1" && state == "virginia")
        {
            return new FormType1Virginia();
        }

        // Add more conditions here for other form types and states

        throw new ArgumentException("Invalid type or state");
    }
}
```
In this example, FormTypeFactory.CreateFormType creates and returns an instance of the appropriate FormType subclass based on the provided type and state. Each FormType subclass implements its own Validate method, encapsulating the validation logic for that form type and state.

Thanks