.NET Singleton Example

// .NET Singleton
sealed class Singleton 
{
    private Singleton() {}
    public static readonly Singleton Instance = new Singleton();
}

This version is dramatically simpler and more intuitive. Is it still a singleton? Let's look at what changed and then decide. We modified the class itself to be sealed (non-inheritable), the lazy initialization code is removed, the Instance() method is removed, and we modified the _instance variable extensively. The changes to the _instance variable include modifying the access level to public, marking the variable as read-only, and initializing the variable at declaration time. Here we can directly define the behavior we want and not be concerned with potential unwanted side effects of the implementation. So what about the advantages of using lazy initialization and the hazards of multiple threads? All of the correct behaviors are built into the .NET Framework. Let's take the first case, lazy initialization.

The main reasons for using lazy initialization initially were to get the behavior of having an instance created on only the first call to the Instance() method, and because there was some openness in the C++ spec that did not define the exact initialization order of static variables. To get desired singleton behavior in C++, a workaround that involved the use of lazy initialization was necessary. What we really care about is that we get the instance created either on or just before the first call to (in this case) the Instance property, and that we have a defined initialization order for static variables in a class. With the .NET Framework, this is exactly the behavior we get. The Framework, during the JIT process, will initialize the static property when (and only when) any method uses this static property. If the property is not used, then the instance is not created. More precisely, what happens during JIT is that the class gets constructed and loaded when any static member of the class is used by any caller. In this case the result is the same.

What about thread-safe initialization? The Framework addresses this too. The Framework internally guarantees thread safety on static type initialization. In other words, in the example above, there is only one instance that would ever be created of the Singleton class. Note also that the property field used to hold the instance of the class is called Instance. This choice better illustrates that this value is an instance of the class as part of the discussion in this article. In the Framework itself there are several classes that use this type of singleton, although the property name used is called Value instead. The concept is exactly the same.

public sealed class Singleton {
    private sealed class SingletonInstanceHolder {
        private SingletonInstanceHolder() {}
        public static readonly Singleton SingletonInstance = new Singleton();
    }

    private Singleton() {}
    
    public static Singleton Instance {
        get { return SingletonInstanceHolder.SingletonInstance; }
    }
}

AVK>>В принципе, если его вобще не использовать, может . А если серьезно, то примеры в студию.

// Singleton
public class BizEntity
{
    public void Foo()
    {
        // do some work
        System1.Logger.Instance.Log("Work done");
    }
}

// IServiceProvider
public class BizEntity
{
    public void Foo()
    {
        // do some work
        Context.GetService<ILogger>().Log("Work done");
    }
}

if (false)
    Singleton.Instance.Foo();

using System;

class Logger
{
    public static readonly Logger Instance = new Logger();

    private Logger()
    {
        Console.WriteLine("Logger initialized");
    }

    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

class Logger2
{
    private class InstanceHolder
    {
        public static readonly Logger2 Instance = new Logger2();
    }

    public static Logger2 Instance
    {
        get { return InstanceHolder.Instance; }
    }

    private Logger2()
    {
        Console.WriteLine("Logger2 initialized");
    }

    public void Log(string message)
    {
        Console.WriteLine(message);
    }
}

class Program
{
    static void Main()
    {
        try
        {
            Console.WriteLine("Do some work");
        }
        catch (Exception ex)
        {
            Logger.Instance.Log(ex.Message);
            Logger2.Instance.Log(ex.Message);
        }
    }
}

public class MySingleton
{
    private static MySingleton _instance = new MySingleton();
    
    public static MySingleton Instance
    {
        get
        {
            return _instance;
        }
    }
}

public class Singleton
{
 private static Singleton _instance;
 public static Singleton GetInstance()
 {
  if (_instance == null)
  {
   lock (typeof(Singleton))
   {
    if (_instance == null)
    {
     _instance = new Singleton();
    }
   }
  }
  return _instance;
 }
}

A>Если синглтон слегка модифицированный, то и решение тоюе будет слегка модифицированным.

Паттерн Singleton
Назначение:
Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа

В общем случае паттерн состоит из четрех основных элементов:

1. Имя......
2. Задача....
3. Решение. Описание элементов дизайна, отношений между ними, функций каждого элемента. Конретный дизайн или реализация не имеются в виду, поскольку паттерн — это шаблон, применимый в самых разных ситуациях. Просто дается абстрактное описание задачи проектирования и того, как она может быть решена с помощью некоего весьма обобщенного сочетания элементов( в нашем случае классов и объектов )
4. Результаты.....

DAN>        // do some work
DAN>        Context.GetService<ILogger>().Log("Work done");
DAN>

// System code
public class Server
{
    public void DoSomeWork()
    {
        ServerContext ctx = new ServerContext();
        ctx.AddService<ILogger>(new FileLogger(...));
        GetEntity(ctx).Foo();
    }
}

// Client code
public class BizEntity
{
    public void Foo()
    {
        // do some work
        Context.GetService<ILogger>().Log("Work done");
    }
}

DAN>Я собственно тоже только хотел сказать что использование фабрики вместо синглтона связность не уменьшает

In computer science, the singleton design pattern is designed to restrict instantiation of a class to one (or a few) objects.

public class Singleton
{
 private static Singleton _instance;
 public static Singleton GetInstance()
 {
  if (_instance == null)
  {
   lock (typeof(Singleton))
   {
    if (_instance == null)
    {
     _instance = new Singleton();
    }
   }
  }
  return _instance;
 }
}

   public class Singleton<T>
   {
      static private T _instance;
      static private object _lock = new object();

      protected Singleton()
      {
      }

      public static T Instance
      {
         get
         {
            if(_instance == null)
            {
               lock(_lock)
               {
                  if(_instance == null)
                  {
                     ConstructorInfo ci = type.GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic,
                        null,
                        new Type[] { },
                        null);
                     _instance = (T)ci.Invoke(null);
                  }
               }
            }
            return _instance;
         }
      }
   }

// .NET Singleton
sealed class Singleton 
{
    private Singleton() {}
    public static readonly Singleton Instance = new Singleton();
}

The main reasons for using lazy initialization initially were to get the behavior of having an instance created on only the first call to the Instance() method...
With the .NET Framework, this is exactly the behavior we get.

What about thread-safe initialization? The Framework addresses this too. The Framework internally guarantees thread safety on static type initialization.

To get desired singleton behavior in C++, a workaround that involved the use of lazy initialization was necessary.

try
{
    // Do some work
}
catch (Exception ex)
{
    Logger.Instance.Log(ex.Message);
}

    public sealed class Singleton 
    {
        private sealed class Core
        {
            private Core()
            {
            }
            public static readonly Singleton Instance = new Singleton();
        }
        private Singleton()
        {
        }
        public static Singleton Instance
        {
            get { return Core.Instance; }
        }
        public void Foo() // Этому методу нужен Instance
        {
        }
        public static void ok()  // Этому методу не нужен Instance
        {
        }
    }

L>Если что-то кажется тебе ошибочным, это не обязательно значит, что это ошибочно. Возможно ты просто не понял для чего это сделано.

A>Согласен, отдельного. Поймай на C# это исключение и я тоже не стану видеть ничего криминального.

catch {}

А>Ненужного Каждый раз инстанс объекта не создается.

Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа

DAN>>В другом вопрос: а как это влияет на связность? Теперь всем приложениям придется реализовывать ILogger

Пусть нам понадобилось запустить код BizEntity в другой системе с совершенно иной реализацией логгера. В первом варианте нам нужно будет перетаскивать исходники и править все вызовы логгера

DAN>>По мне так overhead небольшой — что менять Instance, что менять фабрику т.к. в любом случае придется перелопатить тонну кода клиентского

вместо одного экземпляра нам понадобилось иметь в программе несколько, например для каждой сессии отдельно.

        // do some work
        Context.GetService<ILogger>().Log("Work done");

public static readonly Logger Instance = new Logger();

public static readonly Logger Instance;
static Logger()
{
 Instance = new Logger();
}

Допускает переменное число экземпляров. Паттерн позволяет вам легко изменить свое решение и разрешить появление более одного экземпляра класса. Вы можете применять один и тот же подходдля управления числом экземпляров, используемых в приложении.

public static readonly Logger Instance = new Logger();

public static readonly Logger Instance;
static Logger()
{
 Instance = new Logger();
}

Результаты
У паттерна одиночка есть определенные достоинства:
<...>

допускает переменное число экземпляров. Паттерн позволяет вам легко изменить свое решение и разрешить появление более одного экземпляра класса Singleton. Вы можете применять один и тот же подход для управления числом экземпляров, используемых в приложении. Изменить нужно будет лишь операцию, дающую доступ к экземпляру класса Singleton;