Singleton design pattern

It's main purpose is that there's only one instance of an object and you need to ensure that on no account can anyone create a new one.

Use cases

It is commonly used when creating loggers, because you only need one access point to the logger, and whatever happens you want all classes to log the same place.

Another example is configuration and resource classes, where the system or application's configurations or the application's resources has to be accessed, so you make a singleton, and if any modification happens, every point of interest can immediatelly apply to it (because there's only one single source of truth)

On the implementation side there can be only one problem, and that is thread-safe solution. Of course, your application can be async in no time, but the good part of the Singleton is that you can lock it if bein' modified somewhere, and unlock it when the modification is done. This example is syncrounous, but keep in mind when implementing in a event-driven enviroment.

Example

Class Structure

We can start with the usual boilerplate, all snippets is considered in the class' scope.

using System;

namespace Design_Patterns.Patterns
{
    internal class Singleton
    {
        /*...*/
    }
}

Creating

private static Singleton? instance = null;

private Object[] variables;

private Singleton()
{
    /*example initialisation is shown here*/
    variables = new Object[0];
    /*...*/
}

Did you spot it? The constructor is private, it cannotbe accessed from the outside, and the instance is static, so you can get an object from a class scoped attriburte...

Create the instance

public static Singleton getInstance()
{
    if (instance == null)
    {
        instance = new Singleton();
    }
    return instance;
}

This is quite logical. You don't necessarily need your instance to exist if never read, so only initialize when first accessed.

Of course, if it is crutial to exist at first, you can always use static constructors in c# which will be called when the class is first read by the system.

Many languages have some form of solution for that, kotlin has out of scope methods and the Companion class' init for example

Now what?

Well, you have your syncronous Singleton, everything after that is up to you. Keep in mind that this pattern is creational, so it's main focus is to supervise the creation of the object.