Design patterns: Singleton

Today we will describe the first design pattern or rather anti-pattern, it is officially a design pattern, but for many it is also considered by me as anti-pattern, because it has many disadvantages that we will tell you about, but still is useful for some applications.

First, we will describe the implementation of Singleton in theory and implement Singleton in practice and then describe the advantages and disadvantages of such a solution (next lessons will look similar).

Description and implementation

The purpose of the Singleton pattern is to limit the class instance to one and provide global access to the object.

Singleton implements through a private constructor, and the method that gets this constructor, because the constructor is private so you can not create a class object right away through the constructor only through the GetInstance() method.

Examples in which Singleton would be suitable for implementation are, for example, classes representing devices such as a monitor, computer, laptop or mouse if it is known that there will be only one of these objects, or a class that is used to track events.

It is also important to secure access to classes that implement Singleton from multiple threads, in C # using the keyword lock. In the lesson about concurrency in the C # language section, I told about this key word.

In our practical example, we will implement Singleton to the Shop class from the policy section SOLID principle, it looked like this:

So the Shop class with the implemented Singleton looks like this:

As you can see, we have a rigidly created instance inside the class, and we can not create a second instance because we have a private constructor.

Such a solution has its advantages and disadvantages, unfortunately there are more disadvantages.



– Creating a class instance is invisible to the user.

– Class can independently control the number of own instances.

– creating a new instance has a lazy character, that is, it occurs at the first attempt to use it.


No flexibility, at the code level the number of class instances is limited.

– difficult testing, access to the classes is global.

– It can not be expanded.

– Breaks the SRP(Single-responsibility) principle, one class is responsible for everything

– Breaks the OCP(Open-closed) principle.


That’s all about Singleton.

In the next article, we will talk about the Builder pattern.

This content also you can find on my steemit blog

And on medium:

As a standard, I remind you about the newsletter, which I send notifications about new entries and additional information about the IT world in general.🙂

And NECESSERILY join the DevmanCommunity community on fb, part of the community is in one place 🙂

– site on fb:ławomir Kowalski

– group on fb: DevmanCommunity

Ask, comment underneath at the end of the post, share it, rate it, whatever you want🙂.

If that post was useful for you share it with your friends :)

Post a comment

Notify about