Is Monostat a good cousin of the evil Singleton?

Question

Singleton is definitely one of the most abused and abused patterns. Many of us were infected with singletonitis at some point. Curiously, his close relative, Monostate , is less known and less used. How do you feel about Monostate? Good or just how evil? Is this the best alternative to using Singleton? Could you also refuse to use it, as with Singleton?

Answer 1

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

• Testing
• hidden dependencies
• inflexible
• flow safety
• global status makes it difficult to ensure correctness

Answer 2

how about not using patterns just because?

update: Singleton abuse occurs because people add the template without justification. He often adds arbitrary restrictions that do not bring any benefit. the use of a monostat without justification is perhaps less harmful, but not more justified. if the universe does not crash, if there is more than one instance, than not using it with a template - just create only one instance.

Answer 3

According to this Monostates definition, this note:

"Monostats are evil just like SingletonsAreEvil .

I do not necessarily agree. The basic premise is that Singletones and Monostats are global variables, and since the Globals are evil, so should Singletones and Monostats.

The problem with this line of reasoning is that it does not take into account why the globals are evil. Globals are evil primarily because they are variables that can be obtained outside the local area by chance, just as non-typed languages ​​often allow you to create variables simply by referencing them.

Singlets and monostats cannot cause the same problems, because it is almost impossible to “accidentally” refer to global statics, call the instance method, and then use the instance.

In other words, globals are evil because they cause subtle and difficult problems. Singletones and Monostats do not cause the same problems, so I do not see them as evil for the same reasons that most people seem to be mistaken in this argument.

Now, can synods and monostats cause other problems? Sure. TDD people seem to hate them because they are hard to test with automated testing. Good, great, but for those people who don’t use TDD, these problems do not exist.

Of course, singles may be misused. People who use them simply to avoid passing the instance misuse them. I think Monostates is better for this than singleton.

Many people offer factory templates instead of singletones, but I feel that Factories are just fancy single-pole generators. No, there is no static "instance" method, but it basically does the same thing (when the factory creates one instance of the object that is). Factory. Creation is no different from Singleton.Instance.

EDIT:

One aspect of Singletons and Monostates comparable to Globals is that they are separate and therefore not thread safe. Although this is troubling if you plan to make multi-threaded applications, if you know this, you can take steps to serialize access to shared objects. Thus, this is probably the only area where, as a rule, all three types can be considered as causing problems.

Answer 4

Why do you expect people to discourage the use of Singletons? Creating broad generalizations about singletones is to make broad generalizations about gotos, global variables, etc. There is a place for everyone. None of these things are “evil,” and their misuse does not make them bad to use, it just means that they must be used properly.

Answer 5

The biggest problem with Monostate is that it can lead to confusion on the part of those who use it. Generally speaking, if you create a new instance of an object, you expect it to be exactly that, a new instance with its own state and life cycle. I usually find that unexpected behavior is bad, so I prefer singleton, simply because you know what you get when you use it.

As for whether a template is evil, singletones tend to be abused, but then all the other templates, switch statements, do it for loops or just about anything you would like to mention.

Answer 6

Here is an excerpt from page 127 of design patterns: elements of reusable object-oriented software from Gamma, Helm, Johnson, and Vlissides.

Use the Singleton pattern if

• there must be exactly one instance of the class, and it must be accessible to clients from a known access point
• when a single instance should be an extensible path of a subclass, and clients should be able to use an extended instance without changing their code

Does this really make singles evil only because they abuse and misunderstand?

Answer 7

The deal with Monostate is that you need to know less about the implementation of an object in order to use it. In other words, you save a few keystrokes because you do not need to call the getInstance method of objects (Singleton s = Singleton :: getInstance; s.Method ();) to get a reference to the object, you just use normal language constructs (Monostate ms ; ms.Method ();). Really thin line.

Each langauge programming construct can be flagged as evil because any contrsuct programming language can be abused.

When used wisely, I do not see a single “evil” or “good”.

Answer 8

What 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 provides and clearly reports that there is only one instance.