A>Вот наверное более удачный пример: Оборачиваем в синглетон главное окно (HostWindow.Instance), если клиентский код
A>обращается к экземпляру синглетона до того, как само окно создано, то мы кидаем Exception (ApplicationException). Но клиентский код получит другой
A>Exception — TypeInitializationException. Причем

A>

A>когда вы во второй раз попробуете обратиться к статическому свойству этого типа, исполняющая среда не будет пытаться снова вызвать конструктор типа, а сгенерирует то же исключение, что и на первой итерации. Исполняющая среда не дает конструктору типа еще один шанс. Те же правила действуют, когда исключение генерируется кодом инициализации статического поля, созданным по объявлению этого поля. Как вы уже видели, код инициализации статического поля выполняется в неявном конструкторе типа.

A>Именно эта особенность статического конструктора очень часто может препятствовать использованию static class-а вместо синглетона.

A>Да, и еще — если используется многопоточность, то в той же статье есть параграф Блокировки при выполнении конструкторов.

A>Так что, ИМХО, использование классического синглетона снизит вероятность ошибки. Да и вообще использование статического конструктора не рекоммендуется.

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

Здравствуйте, Аноним, Вы писали:

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

D>>Главное отличие Singlton'a от static класса: время жизни Singlton'a можно
D>>контролировать.

А>Каким образом? Можно пример кода?

Процесс инициализации класса статическим конструктором потобезопасный? Тоесть есть какая нить гарантия, что static конструктор не будет вызван два раза, если к нему обратяться одновременно (допустим на 2-х процессорной тачке) два потока?

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

AK>во фреймворке используются такие классы как Application, Enviroment, которые явно могли быть синглтонами, но MS их делает статиками (вообще не припонню у них синглтона).
AK>Так что должно быть нужно классу особенного, чтобы стать синглтоном вместо статика? в подавляющем большинстве случаев статик классы полностью заменяют синглтоны. Может их и можно назвать реализацией этого паттерна на уровне языка? Ведь они полностью решают проблему, которую должен решать синглтон — нет глобальных объектов, и "копия" единственная. В C# вообще нет понятия глобальных объектов, так что часть проблемы решает сама платформа... значит смысл синглтона должен быть несколько иным чем он был например для с++

AK>хотелось бы узнать, кто что думает по этому поводу?


не знаю, говорили ли здесь, но Application совсем не статический класс, возможно даже и синглтон =)

Application class

public sealed class Application

еще, вот как можно замаскировать синглтон

public class SingletoneStatic
{
  private static SingletoneStatic instance;
  private static SingletoneStatic Instance 
  {
    get
    {
     if (instance == null) instance = new SingletoneStatic();
     retrun  instance;
    }
  }
  public static void StaticMethod()
  {
    Instance.staticMethod();
  }
  public static void staticMethod()
  {
   /*...*/
   }
}

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

D>>>Главное отличие Singlton'a от static класса: время жизни Singlton'a можно
D>>>контролировать.

А>>Каким образом? Можно пример кода?

D>Процесс инициализации класса статическим конструктором потобезопасный? Тоесть есть какая нить гарантия, что static конструктор не будет вызван два раза, если к нему обратяться одновременно (допустим на 2-х процессорной тачке) два потока?

безопасный, безопасный, только сложно контролировать когда он будет вызван — от старта приложения до первого использования класса, может быть вызван в любой момент, в том числе и до main'а, кроме того сложно невозможно контролировать создание экземпляра класса снаружи...

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

WH>Допустим...

Допустим такой вариант: толстый клиент синхронизирует/кеширует данные в собственную CBO бизнес модель, реализованную в виде синглтона. Представьте, пожалуйста, этот синглтон в виде сервиса.

Здравствуйте, <Аноним>, Вы писали:

А>Допустим такой вариант: толстый клиент синхронизирует/кеширует данные в собственную CBO бизнес модель, реализованную в виде синглтона. Представьте, пожалуйста, этот синглтон в виде сервиса.
И что я должен по паре строк спроектировать решение?
Для того чтобы спроектировать адекватную систему мне нужно прочитать и проанализировать требования к вашей системе. Это процесс весьма трудоемкий и делать бесплатно я его не стану.

В данном посте я изложил принцип и показал какие возможности это дает.
Если есть конкретные вопросы спрашивай, а делать экстраполяцию из точки я не буду.

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

WH>В данном посте я изложил принцип и показал какие возможности это дает.
WH>Если есть конкретные вопросы спрашивай, а делать экстраполяцию из точки я не буду.

И все же это довольно конкретный вопрос)
Вот суть вашей первой фразы — "Синглетоны в лес". Из чего можно сделать вывод, что синглтоны не имеют права на жизнь в этом мире.
Я привел пример использования синглтона. По вашей методике я могу переделать его в сервис. Остается только один вопрос.. как обеспечить срок жизни данного сервиса равным сроку жизни самого клиента не используя других синглтонов?)

Здравствуйте, <Аноним>, Вы писали:

А>И все же это довольно конкретный вопрос)
А>Вот суть вашей первой фразы — "Синглетоны в лес". Из чего можно сделать вывод, что синглтоны не имеют права на жизнь в этом мире.
А>Я привел пример использования синглтона. По вашей методике я могу переделать его в сервис. Остается только один вопрос.. как обеспечить срок жизни данного сервиса равным сроку жизни самого клиента не используя других синглтонов?)
Отвечу также конкретно как ты спрашиваешь: Легко и красиво.

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

WH>Отвечу также конкретно как ты спрашиваешь: Легко и красиво.

Ну убедительно таки.
Браво)

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

WH>Здравствуйте, <Аноним>, Вы писали:

А>>И все же это довольно конкретный вопрос)
А>>Вот суть вашей первой фразы — "Синглетоны в лес". Из чего можно сделать вывод, что синглтоны не имеют права на жизнь в этом мире.
А>>Я привел пример использования синглтона. По вашей методике я могу переделать его в сервис. Остается только один вопрос.. как обеспечить срок жизни данного сервиса равным сроку жизни самого клиента не используя других синглтонов?)
WH>Отвечу также конкретно как ты спрашиваешь: Легко и красиво.

Автор не просит конкретной реализации, а направление, проблема повторяется из проекта к проекту и не важно какого рода проект, всегда находятся объекты которые живут пока не выгрузят аппликацию, загрузка их может быть трудоёмким процесом, поетому очень интересно было бы послушать каим образом можно обойтись без синглетонов

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

Мне кажется ты путаёшь тёплое с мягким. У синглота всего одна задача — обеспечить количество экземпляров объекта от 0 до 1. Ни меньше (гы-гы), ни больше. А то что ты описал, это chain of responsibility, не имеющая решительно никакого отношения к singleton. Штука конечно хорошая, но зачем синглтон-то хоронить?
Потом, в твоей реализации сам GuiContext вынужден быть синглтоном, чтобы возвращаемые сервисы были всегда один и тем же объектом (а иначе это уже не эквивалентные решения). Либо надо делать поля m_ISomeGuiService1 статическими... и получить синглотон Мейерса. Вобщем я почитал-почитал то, что ты написал... и рештельно не понял почему это замена синглтону.

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

IDL>Автор не просит конкретной реализации, а направление, проблема повторяется из проекта к проекту и не важно какого рода проект, всегда находятся объекты которые живут пока не выгрузят аппликацию, загрузка их может быть трудоёмким процесом, поетому очень интересно было бы послушать каим образом можно обойтись без синглетонов
Гм... А еще раз перечитать мой пример? Там все есть.

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

A>Мне кажется ты путаёшь тёплое с мягким. У синглота всего одна задача — обеспечить количество экземпляров объекта от 0 до 1. Ни меньше (гы-гы), ни больше.
Ты еще про глобыльную точку доступа забыл... Гы-гы... А такими темпами можно записать в синглетоны все что по недразумению создалось в одном экземпляре.
A> А то что ты описал, это chain of responsibility, не имеющая решительно никакого отношения к singleton. Штука конечно хорошая, но зачем синглтон-то хоронить?
За тем что при правильном проектирование он нафиг не упал...
A>Потом, в твоей реализации сам GuiContext вынужден быть синглтоном, чтобы возвращаемые сервисы были всегда один и тем же объектом
Зачем ему быть синглетоном? Весь смысл что у одной группы формочек свои копии сервисов, а у другой свои.
A>(а иначе это уже не эквивалентные решения).
Эквивалентные с чем? С решением на синглетонах? Так на синглетонах то что я описал не решается. Вернее решается настолько через зад автогеном что я даже думать про такие решения не стану.
A>Либо надо делать поля m_ISomeGuiService1 статическими...
Зачем?
A>и получить синглотон Мейерса.
Чисто С++ные приколы сюда приплетать не нужно.
A>Вобщем я почитал-почитал то, что ты написал... и рештельно не понял почему это замена синглтону.
По тому что делает синглутон не нужным и за одно избавляет от кучи проблем.

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

A>Мне кажется ты путаёшь тёплое с мягким. У синглота всего одна задача — обеспечить количество экземпляров объекта от 0 до 1. Ни меньше (гы-гы), ни больше.
Ошибаешься... Почитай определение паттерна он GOF, там четко сказано, что Sigleton позволяет создавать контролируемое число экземпляров, не один, а именно контролируемое число. Если возникнет такая потребность, то сиглтон позволяет создавать хоть 10 экземпляров, и не создавать 11-й, если нужно ровно 10. Об этом почему-то все время забывают.

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

WH>Ты еще про глобыльную точку доступа забыл... Гы-гы...

Вот именно!

WH>Весь смысл что у одной группы формочек свои копии сервисов, а у другой свои.

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

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

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

A>>Мне кажется ты путаёшь тёплое с мягким. У синглота всего одна задача — обеспечить количество экземпляров объекта от 0 до 1. Ни меньше (гы-гы), ни больше.
IB>Ошибаешься... Почитай определение паттерна он GOF, там четко сказано, что Sigleton позволяет создавать контролируемое число экземпляров, не один, а именно контролируемое число. Если возникнет такая потребность, то сиглтон позволяет создавать хоть 10 экземпляров, и не создавать 11-й, если нужно ровно 10. Об этом почему-то все время забывают.

Что такое GOF? У меня есть небезызвестная "Приёмы объектно ориентированного программирования/Паттерны проектирования" изданая в этом году и там ясно сказано

Паттерн Singlton

Название и классификация паттерна

Одиночка — паттерн, порождающий объекты.

Назначение

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

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

WH>>Весь смысл что у одной группы формочек свои копии сервисов, а у другой свои.
A>Вот, то есть у тебя не эквивалентное решение. Так что тут уместно говорить о разных решениях некоторой конкретной практической задачи, с синглтоном и без него, но не о замене синглтона как такового.
Ессно оно не эквивалентно ибо на синглетоне такое озвереешь делать...
В тоже время если поместить сервис в корневой контекст то мы получим его в одном экземпляре. Те это буде функциональность синглетона.

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

A>Что такое GOF?
Gang of Four (банда четырех) Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, авторы книжки "Design Patterns: Elements of Reusable Object-Oriented Software"

A>У меня есть небезызвестная "Приёмы объектно ориентированного программирования/Паттерны проектирования" изданая в этом году и там ясно сказано
Либо кривой перевод, либо не там смотришь. Там в конце описания паттерна как раз об этом сказано.
Более того, чуть позже вышла книга Влиссидеса "Pattern Hatching: Design Patterns Applied", где давались пояснения и примеры использования в реальных приложениях паттерны из GoF и там этой особенности синглтона было уделено особое внимание.
Синглтон — это именно контролирумое число экземпляров, а не один и только один экземпляр, нет ни одной причины, чтобы не использовать этот паттерн в данном качестве.

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

WH>Ессно оно не эквивалентно

Ну тогда и говрить не о чем.

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

IB>Gang of Four (банда четырех) Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, авторы книжки "Design Patterns: Elements of Reusable Object-Oriented Software"

Вот моя — http://www.onyxbooks.ru/books/21/211/2110/54188.html

IB>Либо кривой перевод, либо не там смотришь. Там в конце описания паттерна как раз об этом сказано.
IB>Более того, чуть позже вышла книга Влиссидеса "Pattern Hatching: Design Patterns Applied", где давались пояснения и примеры использования в реальных приложениях паттерны из GoF и там этой особенности синглтона было уделено особое внимание.
IB>Синглтон — это именно контролирумое число экземпляров, а не один и только один экземпляр, нет ни одной причины, чтобы не использовать этот паттерн в данном качестве.

По моему это ты что-то не так прочитал. Там написано, что может быть несколько точек доступа для одного и того же класса, но ничего не сказано о том, что за одной точкой доступа может скрыватся несколько объектов.