Народ подскжаите как в C# создать Singleton класс?

Здравствуйте, EyfelFenk, Вы писали:

EF>Народ подскжаите как в C# создать Singleton класс?

Обычный static класс..

Здравствуйте, EyfelFenk, Вы писали:

EF>Народ подскжаите как в C# создать Singleton класс?

В рамках одного домена:

public static class Singleton<T>
{
  static Singleton()
  {
    Instance = default(T);
  }

  public T Instance { get; private set; }
}

// второй вариант
public static class Singleton<T>
{
  static Singleton()
  {
    Instance = (T)Activator.CreateInstance();
  }

  public T Instance { get; private set; }
}

// третий вариант
public static class Singleton<T>
{
  public Initialize(params object[] args)
  {
    // сюда дабл-лок и вызов необходимого конструктора
    // код дома, на память не могу вспомнить, студии нет.
  }

  public T Instance { get; private set; }
}

Здравствуйте, EyfelFenk, Вы писали:

EF>Народ подскжаите как в C# создать Singleton класс?

Кажется, вас тут избаловали совсем
Не поддавайтесь

Здравствуйте, EyfelFenk, Вы писали:

EF>Народ подскжаите как в C# создать Singleton класс?

здесь

Здравствуйте, k0stya, Вы писали:

EF>>Народ подскжаите как в C# создать Singleton класс?

K>Обычный static класс..

Синглетон — тип, который может иметь одно-единственное значение. Статический же класс значение не имеет совсем. Если это не понятно, пример другой: синглетон может реализовать какой-либо интерфейс, и экземпляр синглетона может быть передан в какой-либо метод в качестве значения параметра. Со статическим классом это невозможно.

Здравствуйте, EyfelFenk, Вы писали:

EF>Народ подскжаите как в C# создать Singleton класс?

ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, EyfelFenk, Вы писали:

EF>>Народ подскжаите как в C# создать Singleton класс?

_FR>ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

Мне не понятен смысл DBNull.Value, но да, пример синглетона хороший.

У меня в системе синглетоном ещё логгер реализован.

Здравствуйте, _FRED_, Вы писали:

_FR>ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

Хорошо если отойти от синглов, то как например реализовать настройку приложения (класс с параметрами и прочее?) котоырй тока один раз должен инититься?

Здравствуйте, EyfelFenk, Вы писали:

EF>Здравствуйте, _FRED_, Вы писали:

_FR>>ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

EF>Хорошо если отойти от синглов, то как например реализовать настройку приложения (класс с параметрами и прочее?) котоырй тока один раз должен инититься?

На замену Singletone можно использовать ServiceLocator

здесь

Но там достаточно муторное объяснение. Смысл в том, что сам Locator — это Singleton, а он уже по требованию раздает ссылки на другие объекты. Запрос происходит по типу интерфейса, объект класса, который реализует интерфейс нужно получить. В Вашем примере доступ будет выглядеть примерно так.

IApplicationSettings = ServiceLocator.GetInstance<IApplicationSettings>();

Но конкретно для Settings есть стандартные механизмы )) Но для других сервисов — очень удобно использовать, поскольку контролируемо время инициализации, хотя бы.

Здравствуйте, Pavel M., Вы писали:

PM>Но конкретно для Settings есть стандартные механизмы ))

А какие, если это не тайна покрытая мраком? =)

Здравствуйте, EyfelFenk, Вы писали:

_FR>>ИМХО, единственный хороший пример синглетона — DBNull.Value и т.п., то есть самодостаточный неизменяемый класс, не зависящий не от чего во внешнем мире. В остальных случаях лучше даже в простых примерах учиться и привыкать делать по-другому, без синглетонов.

EF>Хорошо если отойти от синглов, то как например реализовать настройку приложения (класс с параметрами и прочее?) котоырй тока один раз должен инититься?

А подчти так жею То есть, пишем класс с настройками (кстати, с 2005-ой студии такой уже есть сам):

class MyAppConfig
{
}

Так же делаем класс приложения:

class MyApp
{
  public MyAppConfig Config { get; private set; }
}

И начинаем:

static void Main()
{
  MyApp app = new MyApp(); // "Главный" объект - один, не статический глобальный, а локальная переменная
  app.Run(…); // Как-то запускаем
}

Далее, в каждый класс, которому это необходимо, _явно_ передаём или MyApp или MyAppConfig. Для небольшого приложения сойдёт. В большом уже потребуется Dependency Injection Container. И ни одной глобальной переменной. ВсЁ, что объекту нужно в него и передаётся.

Здравствуйте, Pavel M., Вы писали:

PM>На замену Singletone можно использовать ServiceLocator
PM>здесь
PM>Но там достаточно муторное объяснение. Смысл в том, что сам Locator — это Singleton,

Ага, дабы избавиться от нескольких синглетонов, давайте заведём один, и все синглетоны в него засунем и обзавём модным словом Если бы это было так, то пользы много не давало бы.

Хочешь верь, хочешь не верь, но можно обойтись совсем без глобальных статический переменных с изменяемым состоянием. И даже _сложного_ в этом ничего нет, не то что _очень сложного_.

Здравствуйте, EyfelFenk, Вы писали:

PM>>Но конкретно для Settings есть стандартные механизмы ))

EF>А какие, если это не тайна покрытая мраком? =)

Managing Application Settings

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, EyfelFenk, Вы писали:

_FR>Далее, в каждый класс, которому это необходимо, _явно_ передаём или MyApp или MyAppConfig. Для небольшого приложения сойдёт. В большом уже потребуется Dependency Injection Container. И ни одной глобальной переменной. ВсЁ, что объекту нужно в него и передаётся.

Ответ сразу к двум постам. Я прекрасно знаю и понимаю, но:
1. Во-первых, ServiceLocator — паттерн, являющийся частью концепции EJB, что , по сути, и является реализацией IoC.
2. Во-вторых, это просто удобно, гораздо удобнее чем передавать ссылки во все объекты создаваемые Не вижу больших минусов в использовании его в проектах малого-среднего размера.

Здравствуйте, Aen Sidhe, Вы писали:

AS>У меня в системе синглетоном ещё логгер реализован.

Вот это как раз то, что многим противникам синглетона и не нравится
Если интересно, то Что не так с синглтоном...

Здравствуйте, _FRED_, Вы писали:

_FR>Хочешь верь, хочешь не верь, но можно обойтись совсем без глобальных статический переменных с изменяемым состоянием. И даже _сложного_ в этом ничего нет, не то что _очень сложного_.

Расскажи, интересно.

Здравствуйте, Aen Sidhe, Вы писали:

AS>У меня в системе синглетоном ещё логгер реализован.

Чем это в твоем случае лучше чем статическими методами?

Здравствуйте, Lloyd, Вы писали:

_FR>>Хочешь верь, хочешь не верь, но можно обойтись совсем без глобальных статический переменных с изменяемым состоянием. И даже _сложного_ в этом ничего нет, не то что _очень сложного_.
L>Расскажи, интересно.

О том, как обойтись без глобальных переменных?

Если по-простому: не заводить таковых. Как? В функции Main создаются необходимые локальные переменные (обычно, одна-единственная). У неё вызывается какой-нить Run. Далее: все данные — это поля (не статические) этой переменной. В качестве одного такого может быть DI-контейнер. Необходимые данные (контейнер или конкретика) передаются в объекты в параметрах конструктора\сеттреах свойств и т.п.

Например, создавай приложение через Smart Client Software Factory: довольно развесистое, но без глобальных переменных.

Это всё, думаю, тебе известно Ты какие-то конкретные трудности видишь?

Здравствуйте, _FRED_, Вы писали:

_FR>Если по-простому: не заводить таковых. Как? В функции Main создаются необходимые локальные переменные (обычно, одна-единственная). У неё вызывается какой-нить Run. Далее: все данные — это поля (не статические) этой переменной.

Соображение первое: Языки программирования могли бы позволять явно специфицировать функции/методы как не имеющие доступа к глобальным переменным, и таким образом помочь описанному выше стилю программирования:

int z;

int add(int x, int y) pure
{
    return x + z; // error
}

Соображение второе: Всегда есть возможность передавать эту локальную определенную в Main переменную в каждую функцию программы, причем этот подход наверняка будет кем-либо с гордостью использован, если Singleton вдруг станет не модным.