Skip to main content

The Singleton (Anti)Pattern

There was a time when the Singleton pattern was a trend... until it was officially declared an anti-pattern.

The singleton is defined by Wikipedia as follows:
... a design pattern that restricts the instantiation of a class to one object.
It is also considered an antipattern, a debatable topic, but nonetheless a generally respected notion such that most developers now actively steer away from the singleton as much as possible.

Regardless, I still use it. I even have an abstraction that let me define singletons (cringe).

SingletonBase.cs
using System;

namespace Mendz.Library
{
    public abstract class SingletonBase<T>
        where T : class
    {
        private static readonly Lazy<T> lazy = 
            new Lazy<T>(() => 
                (T)Activator.CreateInstance(typeof(T), true));

        public static T Instance
        {
            get
            {
                return lazy.Value;
            }
        }
    }
}
Which I use to define a singleton class that can store connection string options.

ConnectionStringOptions.cs
using Mendz.Library;
using System.Collections.Generic;

namespace Mendz.Data
{
    public class ConnectionStringOptions : SingletonBase<ConnectionStringOptions>
    {
        private Dictionary<string, string> _connectionStrings;
        public string this[string name]
        {
            get
            {
                return _connectionStrings[name];
            }
            set
            {
                if (_connectionStrings.ContainsKey(name))
                {
                    _connectionStrings[name] = value;
                }
                else
                {
                    _connectionStrings.Add(name, value);
                }
            }
        }

        private ConnectionStringOptions()
        {
            _connectionStrings = new Dictionary();
        }
    }
}
This code defines a singleton ConnectionStringOptions. It contains a dictionary of connection string options which an application can load on startup so that the connection string options can be available anywhere in the active domain. That statement alone opens up a junkful can of worms summarizing exactly why the singleton is an antipattern. Still, I like to keep it handy. I never advertise the SingletonBase to my team. I only have one real use for it in my library and that is for the ConnectionStringOptions.

Comments

Popular posts from this blog

The Graph Theory in C# (Part 1)

Many developers agree that the best way to express the world in code is through object-oriented programming, or OOP. OOP basically represents everything as objects. In fact, modern OOP languages have the "object" as the base or root class of everything, including the traditionally primitive types like char, integer, float, double and Boolean. From the most basic to the most complicated, they are all just objects in OOP.

The Graph Theory in C# (Part 5)

The Vertex is a class that has properties ID and Value. Both ID and Value must be set. This posed a problem because, in the real world, not everything has an ID. It should be possible to create a Vertex with both ID and Value available. However, it should also be possible to create a Vertex with just the Value, the Vertex internally assigning it a virtual ID.