Is Monostate the good cousin of the evil Singleton?

Question

Singleton is definitely one of the most misused and abused patterns out there. Many of us have been infected with Singletonitis at one point or another. Curiously, its close cousin Monostate is less famous and less used. What is your opinion of Monostate? Good or just as evil? Is it a better alternative to using Singleton? Would you also discourage its use as you would with Singleton?

Answer 1

how about not using patterns just because?

update: abuse of singleton occurs because people add the pattern w/o justification. It often adds arbitrary constraint to no benefit. using monostate w/o justification is perhaps less harmful, but no more justified. if the universe won't collapse if there's more than one instance, than don't enforce it with a pattern - just create only one instance.

Answer 2

Why are you assuming that people would discourage the use of Singletons? Making sweeping generalizations about Singletons is like making sweeping generalizations about gotos, global variables and so on. There is a place for all of them. None of these things are "evil", and their misuse doesn't make them bad to use, it just means they need to be used properly.

Answer 3

The deal with Monostate is that you need to know less about the implementation of the object in order to use it. In other words you save a few keystrokes because you don't have to call the objects getInstance method ( Singleton s = Singleton::getInstance; s.Method(); ) to get a reference to the object, you simply use normal language constructs ( Monostate ms; ms.Method(); ). A fine line indeed.

Every programming langauge construct can be labeled evil because every programming language contrsuct can be abused.

When used reasonably, I see neither one being "evil" or "good."

Answer 4

The biggest problem I have with Monostate is that it can lead to confusion on the part of those using it. Generally speaking, if you create a new instance of an object, you expect it to be just that, a new instance, with its own state and lifecycle. I generally consider unexpected behaviors to be a bad thing, so I prefer the singleton, just because you know what your getting when you use it.

As for whether or not either pattern is evil, singletons tend to get misused, but then so do all of the other patterns, switch statements, for loops, or just about anything else you care to mention.

Answer 5

Here is an excerpt from page 127 of Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides.

Use the Singleton pattern when

• there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point
• when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code

Does it really make singletons evil just because they are misused and misunderstood?

Answer 6

According to this definition of Monostates, is this note:

"Monostates are evil in the same way that SingletonsAreEvil."

I don't necessarily agree. The basic premise is that Singletons and Monostates are global variables, and since Globals are evil, so too must be Singletons and Monostates.

The problem with this line of reasoning is that it doesn't take into account WHY globals are evil. Globals are evil primarily because they are variables that can be accessed outside the local scope accidentally, similarly to how non-typed languages often allow variables to be created simply by referencing them.

Singletons and Monostates can't cause the same kinds of problems, because it's virtually impossible to "accidentally" reference a global static, call it's instance method, then utilized the instance.

In other words, globals are evil because they cause subtle and hard to see problems. Singletons and Monostates do not cause the same kinds of problems, so I don't see them as evil for the same reasons, which is where most people seem to go wrong in this argument.

Now, can singletons and monostates cause other kinds of problems? Sure. Apparently, the TDD people hate them because they are hard to test correctly with automated testing. Ok, fine, but for those people that don't use TDD, those problems don't exist.

Of course singletons can be misused. People that use them simply to avoid passing an instance around are misusing them. I think Monostates are better for that than a singleton.

Many people propose factory patterns instead of singletons, but I feel that Factories are just fancy singleton generators. No, there is no static "instance" method, but it basically does the same thing (when a factory creates a single instance object that is). Factory.Create is no different from Singleton.Instance.

EDIT:

One aspect of Singletons and Monostates that is comparable to Globals is that they are shared, and thus not thread safe. While this is a concern if you plan to do multi-threaded apps, if you know this you can take steps to serialize access to the shared objects. So this is probably the only area where, generally, all three types can be thought of as causing troubles.

Answer 7

Um, monostate is Singleton... so it has the exact same problems.

• testing
• hiding dependencies
• inflexible
• thread safety
• global state makes it difficult to ensure correctness

Answer 8

How about a class with a single instance, but without global access:

public class SingleInstance
{
    private static boolean exhausted = false;

    public SingleInstance()
    {
        if (exhausted)
        {
            throw new IllegalStateException("only one instance allowed");
        }
        exhausted = true;

        [...]
    }

    [...]
}

This avoids the problems of Singleton and MonoState, while it enforces and clearly communicates that there is only one instance.