Re[11]: Singleton против static class c# 2
От: WolfHound  
Дата: 18.05.06 08:11
Оценка:
Здравствуйте, _FRED_, Вы писали:

_FR>Да, например, синглетоном иметь словарь — сессия — что-то ещё Ну это и впрямь не так важно.
Не реентернабельно. Да и геморой это стращный.

_FR>Но мне во всём этом не нравится только одно — необходимость проверки возвращённого GetService(…) значения на null
Ты же тут
Автор: _FRED_
Дата: 17.05.06
 ввел IGenericServiceProvider ну и запиши ему в контракт что в случае отсутствия сервиса вылетает исключение.
Ну и реализация соответствующия
    //Этот GetService возвращает null чтобы быть совместимым с контрактом вреймворка
    public object GetService(Type serviceType)
    {
...
    }

    //А этот GetService кидает исключения
    public T GetService<T>() where T : class
    {
      T service = (T)GetService(typeof(T))
            if (service == null)
                throw new ServiceNotExistException(typeof(T));
      return service;
    }
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[12]: Singleton против static class c# 2
От: _FRED_ Черногория
Дата: 18.05.06 08:25
Оценка:
Здравствуйте, WolfHound, Вы писали:

_FR>>Да, например, синглетоном иметь словарь — сессия — что-то ещё Ну это и впрямь не так важно.
WH>Не реентернабельно. Да и геморой это стращный.
+1

_FR>>Но мне во всём этом не нравится только одно — необходимость проверки возвращённого GetService(…) значения на null
WH>Ты же тут
Автор: _FRED_
Дата: 17.05.06
 ввел IGenericServiceProvider ну и запиши ему в контракт что в случае отсутствия сервиса вылетает исключение.

Боюсь, это должно зависеть от самого сервиса — обязательный он, или нет. Например, есть IMessageService, отвечающий за вывод пользователю некоей информации — он дожен быть всегда: в самом крайнем случае выводить в файл. А, например, IDebugService имеет право отсутствовать. Но да, это всё можно решить внутри GetService.
... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»
Help will always be given at Hogwarts to those who ask for it.
Re[13]: Singleton против static class c# 2
От: WolfHound  
Дата: 18.05.06 09:34
Оценка: +1
Здравствуйте, _FRED_, Вы писали:

_FR>Боюсь, это должно зависеть от самого сервиса — обязательный он, или нет. Например, есть IMessageService, отвечающий за вывод пользователю некоей информации — он дожен быть всегда: в самом крайнем случае выводить в файл. А, например, IDebugService имеет право отсутствовать. Но да, это всё можно решить внутри GetService.
Криво это. Если уж на то пошло то GetService трогать не нужно. Нужно в контексте завести методы для получения тех или иных сервисов через GetService. И уже при реализации этих методов решать обязательный сервис или нет.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Singleton против static class c# 2
От: SerkMan  
Дата: 18.05.06 12:49
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Почти. Идея таже только ребята из мелкософта ИМХО перемудрили с реализацией.
WH>Особенно мне во всем этом деле не нравится IServiceContainer совершенно не контролируемая штука.
WH>Да и остальные решения весьма сомнительные... Зачем IComponent'у IDisposable? Зачем ISite'у Name и DesignMode?

Данный набор сервисо проектировался для реализации DesignTime модели.
Если не будет свойства Name как возможно различить несколько экземпляров одного типа в одном хосте.
А как узнать находится ли компонент в дизан тайм.

Конечно модель спроектированная MS не только для дизайнера применима.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[9]: Singleton против static class c# 2
От: WolfHound  
Дата: 18.05.06 14:14
Оценка:
Здравствуйте, SerkMan, Вы писали:

SM>Данный набор сервисо проектировался для реализации DesignTime модели.
SM>Если не будет свойства Name как возможно различить несколько экземпляров одного типа в одном хосте.
SM>А как узнать находится ли компонент в дизан тайм.
Я прекрасно знаю зачем туда засунули эти свойства. Лично адаптировал дизайнер форм под свои компоненты.

SM>Конечно модель спроектированная MS не только для дизайнера применима.
Она избыточна. Названные выше свойства ненужны ни для чего кроме дизайнера.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Singleton против static class c# 2
От: SerkMan  
Дата: 18.05.06 14:45
Оценка: +1
Здравствуйте, WolfHound, Вы писали:

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

SM>>Данный набор сервисо проектировался для реализации DesignTime модели.
SM>>Если не будет свойства Name как возможно различить несколько экземпляров одного типа в одном хосте.
SM>>А как узнать находится ли компонент в дизан тайм.
WH>Я прекрасно знаю зачем туда засунули эти свойства. Лично адаптировал дизайнер форм под свои компоненты.

SM>>Конечно модель спроектированная MS не только для дизайнера применима.
WH>Она избыточна. Названные выше свойства ненужны ни для чего кроме дизайнера.

Но вообще некотрые сервисы использовать нормально, но а вся модель избыточна не для дизайн тайма, с этим я согласен (и не опровергал):
Данный набор сервисо проектировался для реализации DesignTime модели.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[4]: Singleton против static class c# 2
От: IDL  
Дата: 20.05.06 16:02
Оценка: -1 :)
Здравствуйте, WolfHound, Вы писали:

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

WH>>>Синглетоны в лес к товарищу волку который знает кого кушать... Статик классы тудаже.
WH>>>Вместо синглетонов нужно использовать контексты которые реализуют IServiceProvider. Синглетоны имеют смысл ОЧЕНЬ редко. И эти исключения скорее подтверждают правила.

В>>А можно по подробней?
WH>Допустим у нас есть некоторое приложение состоящие из нескольких уровней.
WH>
WH>class RootContext : IServiceProvider
WH>{
WH>    ISomeRootService1 m_ISomeRootService1 = new SomeRootService1Impl();
WH>    ISomeRootService2 m_ISomeRootService2 = new SomeRootService2Impl();
WH>    ISomeRootService3 m_ISomeRootService3 = new SomeRootService3Impl();

WH>    public object GetService(Type serviceType)
WH>    {
WH>        if (serviceType == typeof(ISomeRootService1))
WH>            return m_ISomeRootService1;
WH>        if (serviceType == typeof(ISomeRootService2))
WH>            return m_ISomeRootService2;
WH>        if (serviceType == typeof(ISomeRootService3))
WH>            return m_ISomeRootService3;
WH>        return null;
WH>    }
    
WH>    //Тут могут быть еще какието методы и свойства специфичные для этого контекста
WH>}

WH>class SessionContext : IServiceProvider
WH>{
WH>    RootContext m_RootContext;
WH>    public SessionContext(RootContext rootContext)
WH>    {
WH>        m_RootContext = rootContext;
WH>    }
    
WH>    ISomeSessionService1 m_ISomeSessionService1 = new SomeSessionService1Impl();
WH>    ISomeSessionService2 m_ISomeSessionService2 = new SomeSessionService2Impl();
WH>    ISomeSessionService3 m_ISomeSessionService3 = new SomeSessionService3Impl();

WH>    public object GetService(Type serviceType)
WH>    {
WH>        if (serviceType == typeof(ISomeSessionService1))
WH>            return m_ISomeSessionService1;
WH>        if (serviceType == typeof(ISomeSessionService2))
WH>            return m_ISomeSessionService2;
WH>        if (serviceType == typeof(ISomeSessionService3))
WH>            return m_ISomeSessionService3;
WH>        return m_RootContext.GetService(serviceType);
WH>    }
    
WH>    //Тут могут быть еще какието методы и свойства специфичные для этого контекста
WH>}

WH>class GuiContext : IServiceProvider
WH>{
WH>    SessionContext m_SessionContext;
WH>    public GuiContext(SessionContext sessionContext)
WH>    {
WH>        m_SessionContext = sessionContext;
WH>    }
    
WH>    ISomeGuiService1 m_ISomeGuiService1 = new SomeGuiService1Impl();
WH>    ISomeGuiService2 m_ISomeGuiService2 = new SomeGuiService2Impl();
WH>    ISomeGuiService3 m_ISomeGuiService3 = new SomeGuiService3Impl();

WH>    public object GetService(Type serviceType)
WH>    {
WH>        if (serviceType == typeof(ISomeGuiService1))
WH>            return m_ISomeGuiService1;
WH>        if (serviceType == typeof(ISomeGuiService2))
WH>            return m_ISomeGuiService2;
WH>        if (serviceType == typeof(ISomeGuiService3))
WH>            return m_ISomeGuiService3;
WH>        return m_SessionContext.GetService(serviceType);
WH>    }
    
WH>    //Тут могут быть еще какието методы и свойства специфичные для этого контекста
WH>}
WH>

WH>При такой схеме в одном приложении могут быть несколько сессий. Причем сервивы уровня сессии для каждой сессии свои, а сервисы корневого уровня доступны всем.
WH>Также у в одной сессии может быть несколько отображений. И опять сервисы уровня отображения у каждого отображения свои.

WH>Теперь нам вдруг на уровне Gui понадобилось логирование. Но создать этот сревис можно только на корневом уровне ибо только он знает где лежит приложение итп.
WH>Меняем SessionContext так
WH>
WH>class RootContext : IServiceProvider
WH>{
WH>    ISomeRootService1 m_ISomeRootService1 = new SomeRootService1Impl();
WH>    ISomeRootService2 m_ISomeRootService2 = new SomeRootService2Impl();
WH>    ISomeRootService3 m_ISomeRootService3 = new SomeRootService3Impl();
WH>    ILogger m_Logger = new LoggerImpl();
WH>
WH>    public object GetService(Type serviceType)
WH>    {
WH>        if (serviceType == typeof(ILogger))
WH>            return m_Logger;
WH>        if (serviceType == typeof(ISomeRootService1))
WH>            return m_ISomeRootService1;
WH>        if (serviceType == typeof(ISomeRootService2))
WH>            return m_ISomeRootService2;
WH>        if (serviceType == typeof(ISomeRootService3))
WH>            return m_ISomeRootService3;
WH>        return null;
WH>    }
    
WH>    //Тут могут быть еще какието методы и свойства специфичные для этого контекста
WH>}
WH>

WH>Теперь за счет этой механики логер доступен всем нижележащим слоям. При этом нам не пришлось трогать контексты кроме корневого.

WH>Потом нам понадобилось чтобы в лог добавлялась информация о том из какой сессии идет запись.
WH>Меняем SessionContext так

WH>
WH>class SessionContext : IServiceProvider
WH>{
WH>    ILogger m_Logger;
WH>    RootContext m_RootContext;
WH>    public SessionContext(RootContext rootContext)
WH>    {
WH>        m_RootContext = rootContext;
WH>        m_Logger = new SessionLogger(SessionInfo, (ILogger)m_RootContext.GetService(typeof(ILogger)));
WH>    }
    
WH>    ISomeSessionService1 m_ISomeSessionService1 = new SomeSessionService1Impl();
WH>    ISomeSessionService2 m_ISomeSessionService2 = new SomeSessionService2Impl();
WH>    ISomeSessionService3 m_ISomeSessionService3 = new SomeSessionService3Impl();

WH>    public object GetService(Type serviceType)
WH>    {
WH>        if (serviceType == typeof(ILogger))
WH>            return m_Logger;
WH>        if (serviceType == typeof(ISomeSessionService1))
WH>            return m_ISomeSessionService1;
WH>        if (serviceType == typeof(ISomeSessionService2))
WH>            return m_ISomeSessionService2;
WH>        if (serviceType == typeof(ISomeSessionService3))
WH>            return m_ISomeSessionService3;
WH>        return m_RootContext.GetService(serviceType);
WH>    }
    
WH>    //Тут могут быть еще какието методы и свойства специфичные для этого контекста
WH>}
WH>

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

WH>Таки образом мы может на каждом уровне добавлять свои срвисы, замещать сервисы нижних уровней и даже скрывать сервисы нижних уровней.

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



Идея хорошая, но когда создаётся контекст? Не ресурсоёмкий ли он. Если взять Веб аппликацию, то надо будет при каждом запросе его создавать, не дороговато?
Re[5]: Singleton против static class c# 2
От: WolfHound  
Дата: 20.05.06 16:21
Оценка:
Здравствуйте, IDL, Вы писали:

И зачем было цитировать ВСЕ? Тут за такие дела банят. Так что в следующий раз вырезай лишние.

IDL>Идея хорошая, но когда создаётся контекст? Не ресурсоёмкий ли он. Если взять Веб аппликацию, то надо будет при каждом запросе его создавать, не дороговато?
Шутку оценил. Смешно.
По сравнению с генерацией html это просто ничто.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Singleton против static class c# 2
От: IDL  
Дата: 20.05.06 16:56
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>И зачем было цитировать ВСЕ? Тут за такие дела банят. Так что в следующий раз вырезай лишние.

IDL>>Идея хорошая, но когда создаётся контекст? Не ресурсоёмкий ли он. Если взять Веб аппликацию, то надо будет при каждом запросе его создавать, не дороговато?
WH>Шутку оценил. Смешно.
WH>По сравнению с генерацией html это просто ничто.

Контексты разные бывают.
Хотя в принципе можно делать, иницилизацию по требованию разных сервисов.
У нас есть много синглетонов, инизиализация которых ресурсоёмкая операция, они содержат достаточно много словарей и много разного ещё, загруженного из базы данных. Как Вы в подобных случаях поступаете.
Re: Singleton против static class c# 2
От: Arboz Россия  
Дата: 21.05.06 12:37
Оценка:
Здравствуйте, AKoldin, Вы писали:

AK>Так что должно быть нужно классу особенного, чтобы стать синглтоном вместо статика?

Из книги: Гамма, Хелм "Приемы объектно-ориентированного проектирования" выдержки касающиеся сабжа:

У патерна Singleton есть определенные достоинства перед использованием статических функций членов.

1. Контролируемый доступ к единственному экземпляру.
Через свойство Instance вы можете в одном месте контролировать доступ.

2. Допускает уточнение операций и представленя.
От класса Singleton можно порождать подклассы.
Статические функции-члены не могут быть виртуальными в C# (C++).

3. Допускает переменное число экземпляров
Как правильно было отмечено здесь
Автор: mrozov
Дата: 12.05.06



Да и при использовании статики
"у нас может не быть информации для инстанциирования любого одиночки во время статической инициализации.
Одиночке могут быть необходимы данные, вычисляемые позже, во время выполнения программы."


Если этого ничего не надо, то static class вполне подходит.
Re[7]: Singleton против static class c# 2
От: WolfHound  
Дата: 21.05.06 16:35
Оценка:
Здравствуйте, IDL, Вы писали:

IDL>Контексты разные бывают.
IDL>Хотя в принципе можно делать, иницилизацию по требованию разных сервисов.
IDL>У нас есть много синглетонов, инизиализация которых ресурсоёмкая операция, они содержат достаточно много словарей и много разного ещё, загруженного из базы данных. Как Вы в подобных случаях поступаете.
С ASP.NET я дел не имел. Но судя по тому что я читал там можно сделать както так:
В Global.asax надо написать что-то типа
    void Application_Start(object sender, EventArgs e) 
    {
        Application[typeof(RootContext).AssemblyQualifiedName] = new RootContext();

    }
    
    void Session_Start(object sender, EventArgs e) 
    {
        RootContext rootContext = (RootContext)Application[typeof(RootContext).AssemblyQualifiedName];
        Session[typeof(SessionContext).AssemblyQualifiedName] = new SessionContext(rootContext);
    }

RootContext — содержит сервисы уровня приложения.
SessionContext — содержит сервисы уровня сессии.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Singleton против static class c# 2
От: Варвар США  
Дата: 21.05.06 16:49
Оценка:
Здравствуйте, Arboz, Вы писали:

A>Из книги: Гамма, Хелм "Приемы объектно-ориентированного проектирования" выдержки касающиеся сабжа:

A>У патерна Singleton есть определенные достоинства перед использованием статических функций членов...

Это новая редакция? Держу в руках мой экземпляр книги издательства Питер 2001 года (стр. 132) и там нет ни сравнения со статическими функциями, ни упоминания С#
И вместо сердца каменный топор...
Re[8]: Singleton против static class c# 2
От: Аноним  
Дата: 21.05.06 17:29
Оценка: :)
Здравствуйте, WolfHound, Вы писали:

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

IDL>>Контексты разные бывают.
IDL>>Хотя в принципе можно делать, иницилизацию по требованию разных сервисов.
IDL>>У нас есть много синглетонов, инизиализация которых ресурсоёмкая операция, они содержат достаточно много словарей и много разного ещё, загруженного из базы данных. Как Вы в подобных случаях поступаете.
WH>С ASP.NET я дел не имел. Но судя по тому что я читал там можно сделать както так:
WH>В Global.asax надо написать что-то типа
WH>
WH>    void Application_Start(object sender, EventArgs e) 
WH>    {
WH>        Application[typeof(RootContext).AssemblyQualifiedName] = new RootContext();

WH>    }
    
WH>    void Session_Start(object sender, EventArgs e) 
WH>    {
WH>        RootContext rootContext = (RootContext)Application[typeof(RootContext).AssemblyQualifiedName];
WH>        Session[typeof(SessionContext).AssemblyQualifiedName] = new SessionContext(rootContext);
WH>    }

WH>

WH>RootContext — содержит сервисы уровня приложения.
WH>SessionContext — содержит сервисы уровня сессии.

Это вы, как умели, написали реализацию синглтона RootContext...
Re[3]: Singleton против static class c# 2
От: Arboz Россия  
Дата: 21.05.06 18:26
Оценка:
Здравствуйте, Варвар, Вы писали:

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

A>>Из книги: Гамма, Хелм "Приемы объектно-ориентированного проектирования" выдержки касающиеся сабжа:

A>>У патерна Singleton есть определенные достоинства перед использованием статических функций членов...

В>Это новая редакция? Держу в руках мой экземпляр книги издательства Питер 2001 года (стр. 132) и там нет ни сравнения со статическими функциями, ни упоминания С#

Оно и есть.

A>>Из книги: Гамма, Хелм "Приемы объектно-ориентированного проектирования" выдержки, касающиеся сабжа
Я имел ввиду — близко к тексту.

Упоминание про C# было в связи с тем, что, как и в C++,, статические функции-члены не могут быть виртуальными.
Re[9]: Singleton против static class c# 2
От: WolfHound  
Дата: 21.05.06 18:53
Оценка: :)
Здравствуйте, <Аноним>, Вы писали:

А>Это вы, как умели, написали реализацию синглтона RootContext...
Дело в том что в любом приложении есть некий корневой контекст из которого ветвится большое дерево контекстов. При этом код создающий дочерние контексты имеет ссылку на базовый контекст.
Но в данном случае вмешивается ASP.NET который не расчитан на такую архитектуру. По этому приходится использовать средства ASP.NET для того чтобы передать базовый контекст коду создающему дочерний контекст.
Те в данном случае синглетон был навязан используемой библиотекой. К счастью разрушающие действие этого синглитона удалось локализовать в одном методе.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[10]: Singleton против static class c# 2
От: Аноним  
Дата: 21.05.06 19:16
Оценка: +1 :)
WH>Дело в том что в любом приложении есть некий корневой контекст из которого ветвится большое дерево контекстов. При этом код создающий дочерние контексты имеет ссылку на базовый контекст.
WH>Но в данном случае вмешивается ASP.NET который не расчитан на такую архитектуру. По этому приходится использовать средства ASP.NET для того чтобы передать базовый контекст коду создающему дочерний контекст.
WH>Те в данном случае синглетон был навязан используемой библиотекой. К счастью разрушающие действие этого синглитона удалось локализовать в одном методе.

Т.е. существует некая архитектура или библиотека, которая, в отличие от ASP.NET, гарантирует что корневой контекст будет инициализирован только один раз и существует в единственном экземпляре?
Re[2]: Singleton против static class c# 2
От: AKoldin  
Дата: 22.05.06 03:39
Оценка:
A>1. Контролируемый доступ к единственному экземпляру.
A>Через свойство Instance вы можете в одном месте контролировать доступ.
Принципиально от статика не отличается

A>2. Допускает уточнение операций и представленя.
A>От класса Singleton можно порождать подклассы.
A>Статические функции-члены не могут быть виртуальными в C# (C++).
С этим достоинством согласен, но на мой взгляд, это не частый случай, а лучше тут вообще обойтись без синглтона

A>3. Допускает переменное число экземпляров
A>Как правильно было отмечено здесь
Автор: mrozov
Дата: 12.05.06

А синглтон ли это вообще , Небольшой парадокс с самим определением возникает. Тут нужно было бы говорить о том как синглтон одним движением руки превращается... (это я книгу критикую — иногда полезно, но редко


A>Да и при использовании статики
A>"у нас может не быть информации для инстанциирования любого одиночки во время статической инициализации.
A>Одиночке могут быть необходимы данные, вычисляемые позже, во время выполнения программы."
Эта проблема для шарпа не актуальна (с его вызовом статик конструктора), как это есть для с++, по которому в основном и строились паттерны


A>Если этого ничего не надо, то static class вполне подходит.
согласен
Re[3]: Singleton против static class c# 2
От: Arboz Россия  
Дата: 22.05.06 06:23
Оценка: +1
Здравствуйте, AKoldin, Вы писали:

A>>1. Контролируемый доступ к единственному экземпляру.
A>>Через свойство Instance вы можете в одном месте контролировать доступ.
AK>Принципиально от статика не отличается
Отличается количеством управляемых точек доступа: в синглетоне — одно место, в статик классе — каждая функция-член.

A>>Да и при использовании статики
A>>"у нас может не быть информации для инстанциирования любого одиночки во время статической инициализации.
A>>Одиночке могут быть необходимы данные, вычисляемые позже, во время выполнения программы."
AK>Эта проблема для шарпа не актуальна (с его вызовом статик конструктора), как это есть для с++, по которому в основном и строились паттерны
Как же не актуальны? Например, берем класс, предоставляющий доступ к DataSet-у. В конструкторе, нам необходимо проинициализировать этот DataSet. С синглетоном все понятно, а вот со статик классом как быть?
Его конструктор вообще может быть вызван ДО входа в функцию Main, как это описано здесь
Автор: Mab
Дата: 18.05.06
.
Re[4]: Помогите с dll!
От: AKoldin  
Дата: 22.05.06 08:40
Оценка:
AK>>Эта проблема для шарпа не актуальна (с его вызовом статик конструктора), как это есть для с++, по которому в основном и строились паттерны
A>Как же не актуальны? Например, берем класс, предоставляющий доступ к DataSet-у. В конструкторе, нам необходимо проинициализировать этот DataSet. С синглетоном все понятно, а вот со статик классом как быть?
A>Его конструктор вообще может быть вызван ДО входа в функцию Main, как это описано здесь
Автор: Mab
Дата: 18.05.06
.

Тамже описано, что если определить статичный конструктор, то вызываться он будет именно при первом использовании класса,
Re[5]: Помогите с dll!
От: Arboz Россия  
Дата: 22.05.06 09:32
Оценка: +1
Здравствуйте, AKoldin, Вы писали:


AK>Тамже описано, что если определить статичный конструктор, то вызываться он будет именно при первом использовании класса.
Да. Но я не то хотел сказать. Я хотел подчеркнуть, что у статического конструктора (или, как его называют, конструктора типа)
есть свой перечень особенностей, его можно прочитать, как предлагает DuШes здесь


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

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


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

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

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