Re[6]: Помогите с dll! - Философия программирования

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

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

В>А можно по подробней?
Допустим у нас есть некоторое приложение состоящие из нескольких уровней.

class RootContext : IServiceProvider
{
    ISomeRootService1 m_ISomeRootService1 = new SomeRootService1Impl();
    ISomeRootService2 m_ISomeRootService2 = new SomeRootService2Impl();
    ISomeRootService3 m_ISomeRootService3 = new SomeRootService3Impl();

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

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

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

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

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

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

Теперь нам вдруг на уровне Gui понадобилось логирование. Но создать этот сревис можно только на корневом уровне ибо только он знает где лежит приложение итп.
Меняем SessionContext так

class RootContext : IServiceProvider
{
    ISomeRootService1 m_ISomeRootService1 = new SomeRootService1Impl();
    ISomeRootService2 m_ISomeRootService2 = new SomeRootService2Impl();
    ISomeRootService3 m_ISomeRootService3 = new SomeRootService3Impl();
    ILogger m_Logger = new LoggerImpl();

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

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

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

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

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

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

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

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

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Он делает синглитон в его классической реализации не нужным.

Может я чего-то и не догоняю, но в том что ты описал я не увидел особого отличия от паттерна Service Layer. И сделать сервис-провайдер синглетоном вполне может оказаться куда более удобным чем передача его экземпляра. Т.е. во всем что ты описал — аналог собственно синглтона это та самая "передача экмзепляра", которую вполне и без сервис лаера можно использовать и считать это чем-то более продвинутым чем синглетон мне кажется несколько затруднительным.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

WH>Вот ведь как нехорошо то получается... некоторые сесии хотят чтобы обращения к базе логировались... другие хотят блокировать некоторые запросы которые идут от бизнес логики, а третьи сессии вот ведь гады какие полезли в другую базу...

А вот если нет таких сессий? И приложение однопользовательское — или уж, во всяком случае, не допускает несколько одновременно залогиненных пользователей? И что-то мне сдается, что это куда более распространенный вариант, чем ты описываешь.
Ни разу кстати не писал локальный дата-лаер с которым работает одновременно несколько различных сессий с разными требованиями к фунцкиональности.

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

А у меня — наоборот — больше тривиальные. В итоге — нашли ли мы silver bullet?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, AKoldin,

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

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

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

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

Еще одно важное преимущество синглтона — то, что его можно сериализовать.

А вообще по моему и синглтоны и статические классы это "зло", и лучше их не пользовать, а если все таки приходится то хорошо подумать и все равно не пользовать (ну разве что за исключение случаев типа фабрик). И сам фреймворк тому подтверждение там есть несколько очень неудачных статических классов(например ServicePointManager).

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

ЗЫ. Можно разделить тему и продолжить в отдельной ветке обсуждать component-conteiner-service модель.

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

_FR>При использовании такого подхода удалось ли Вам полностью избавиться от синглетонов?
Да. Удалось.
_FR>Если синглетоны всё же были,
Был они класс с кучей static методов которые читали и анализировали метаинформацию типов. Потом в этот класс добавили несколько кешей для того чтобы рефлекшен лишний раз не трогать. Была мысль превратить и его в сервис но омобого смысла в этом небыло да и других задач хватало.
_FR>то по каким признакам класс попадал в разряд сервисов или "одиночек"?
По глупости.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, 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>В реальных приложениях и слоев больше и сервисов не одни десяток так что механизм который позволяет держать этот зоопарк под контролем не помешает.

Идея хорошая, но когда создаётся контекст? Не ресурсоёмкий ли он. Если взять Веб аппликацию, то надо будет при каждом запросе его создавать, не дороговато?

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

Т.е. существует некая архитектура или библиотека, которая, в отличие от ASP.NET, гарантирует что корневой контекст будет инициализирован только один раз и существует в единственном экземпляре?

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

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

A>Верно, у меня тоже самое написано. Я это склонен воспринимать как множественные точки входа, а не множество экземпляров за одной точкой входа.

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

A> Но ИМХО и не имеет смысла, так как мы с тобой умудряемся один и тот же текст читать по-разному.
Для меня было откровением, что процитированный текст можно воспринять как-то по другому. Извини, больше беспокоить не буду..

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

V>В этой идее мне не нравится то, что не нравится во всем динамическом. Ведь для динамических языков никакой IServiceProvider и нафик не нужен, сечешь? Всякие IServiceProvider — это попытки придать динамических качеств проекту, собранному на статических языках.
Не всегда можно (рентабельно) уходить от динамики. Иногда некоторые части гораздо лучше получаются при использовании динамики. Но динамику нужно граничевать там где она действительно нужна. И эта система именно этим и занимается.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Нет не кажется. Как ты думаешь почему я и не только я послал синглитоны в лес?
WH>Просто по тому что они очень сильно связывают программу, а сильная связанность ничего кроме гемороя не дает.

Т.е. то что ты предлагаешь — это универсальное решение, которое всегда можно и нужно использовать вместо синглетонов? В противном случае я не понимаю, о чем спор.

WH>Например смотри мое сообщение как ты думаешь если бы логер сделали синглитоном (что очень часто с ним и делают) то можно было бы также легко добавить информацию о сессии в контексте которой происходит запись в лог?

Прекрасно. Никто же не говорит, что нужно всегда использовать синглтоны. Приводить примеры где синглтон будет кстати? Просто ты привел решение, которое никак не заменяет и вообще полностью перпендикулярно синглтонам.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

_FR>>

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

В>А зачем его передавать как параметр?

Он один и доступен из любого места.
Например для сериализации — передается как параметр.

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

ВВ>>Прекрасно. Никто же не говорит, что нужно всегда использовать синглтоны. Приводить примеры где синглтон будет кстати? Просто ты привел решение, которое никак не заменяет и вообще полностью перпендикулярно синглтонам.
WH>Попробуй.

Да все очень просто — требуется глобальный инстанс в домене (или даже не только в домене) приложения. Примеры — файл конфига, глобальный сервис провайдер (например, в случае если этот паттерн используется при работе с плагинами), сервис ремотинг, фасад слоя доступа к данным и пр.
Как только мы попробуем сущности, изначально расчитанные на "общий" доступ, передвать каким-либо образом вместо того, чтобы делать их статиками/синглетонами, то свяжем весь остальной код не меньше, обязав его следовать определенному контракту — реализовывать специальным образом конструктор или определять специальный метод — что тоже особенно не весело.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

AK>хотелось бы узнать, кто что думает по этому поводу?
Первое преимущество синглтона, приходящее на ум — возможность поддержки интерфейсов или абстрактных классов
типа как-то так (совершенно от балды пример):

private class ClientConfig : IEnumerable {blah-blah-blah}

private void FillSomething(IEnumerable listEntries) {blah-blah-blah}

private void MyMegaCoolFunction()
{
     FillList(ClientConfig.Instance);
}

Ну и, сооответственно, можно мутить фабрики синглтонов (правда не могу с ходу придумать где оно надо)

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

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

_FR>>>Например, экземпляр ApplicationContext — синглетон. А передавать его нужно в Application.Run(ApplicationContext context).
В>>ApplicationContext — не синглтон!

_FR>Да ты что!
_FR>

_FR>using System;
_FR>using System.Windows.Forms;

_FR>namespace WindowsApplication1
_FR>{
_FR>  internal partial class MyForm : Form
_FR>  {
_FR>    public MyForm()
_FR>    {
_FR>    }
_FR>  }

_FR>  internal class AppContext : ApplicationContext
_FR>  {
_FR>    public static readonly AppContext Instance = new AppContext();

_FR>    private AppContext()
_FR>    {
_FR>      MainForm = new MyForm();
_FR>    }
_FR>  }

_FR>  static class Program
_FR>  {
_FR>    [STAThread]
_FR>    static void Main()
_FR>    {
_FR>      Application.Run(AppContext.Instance);
_FR>    }
_FR>  }
_FR>}
_FR>

ApplicationContext — не синглтон

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

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

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

А можно по подробней?

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

_FR>Если это так, то зачем унифицированный доступ? Почему нельзя сделать сервисы открытыми свойствами?
И при появлении каждого нового сервиса протаптывать его во всех контекстах? А не озвереешь?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>И? Как ты для каждой сессии заведешь свою копию сервисов уровня сессии?

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

_FR>Боюсь, это должно зависеть от самого сервиса — обязательный он, или нет. Например, есть IMessageService, отвечающий за вывод пользователю некоей информации — он дожен быть всегда: в самом крайнем случае выводить в файл. А, например, IDebugService имеет право отсутствовать. Но да, это всё можно решить внутри GetService.
Криво это. Если уж на то пошло то GetService трогать не нужно. Нужно в контексте завести методы для получения тех или иных сервисов через GetService. И уже при реализации этих методов решать обязательный сервис или нет.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

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

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

Но вообще некотрые сервисы использовать нормально, но а вся модель избыточна не для дизайн тайма, с этим я согласен (и не опровергал):
Данный набор сервисо проектировался для реализации DesignTime модели.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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...

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

А>Это вы, как умели, написали реализацию синглтона RootContext...
Дело в том что в любом приложении есть некий корневой контекст из которого ветвится большое дерево контекстов. При этом код создающий дочерние контексты имеет ссылку на базовый контекст.
Но в данном случае вмешивается ASP.NET который не расчитан на такую архитектуру. По этому приходится использовать средства ASP.NET для того чтобы передать базовый контекст коду создающему дочерний контекст.
Те в данном случае синглетон был навязан используемой библиотекой. К счастью разрушающие действие этого синглитона удалось локализовать в одном методе.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

A>>Да и при использовании статики
A>>"у нас может не быть информации для инстанциирования любого одиночки во время статической инициализации.
A>>Одиночке могут быть необходимы данные, вычисляемые позже, во время выполнения программы."
AK>Эта проблема для шарпа не актуальна (с его вызовом статик конструктора), как это есть для с++, по которому в основном и строились паттерны
Как же не актуальны? Например, берем класс, предоставляющий доступ к DataSet-у. В конструкторе, нам необходимо проинициализировать этот DataSet. С синглетоном все понятно, а вот со статик классом как быть?
Его конструктор вообще может быть вызван ДО входа в функцию Main, как это описано здесь.

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

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

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

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

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

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

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

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

A>

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

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

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

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

после таких доводов сложно не согласиться

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

Вот именно!

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>Синглтон — это именно контролирумое число экземпляров, а не один и только один экземпляр, нет ни одной причины, чтобы не использовать этот паттерн в данном качестве.

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

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

A>Это очень плохое описание, так как оно позволяет трактовать по-разному цитату выше.
Цитату выше нельзя трактовать по разному. Английское слово instance переводится на русский как экземпляр. Множество экземпляров синглтона означает именно множество экземпляров, а не множество способов добраться до одного экземпляра.

A>Я говорю о том что в цитате выше говорится о множественных глобальных точках входа.
В цитате выше нет ни слова о глобальных точках входа. Зато там несколько раз упоминается слово экземпляр, как это еще до тебя донести?

A>В любом случае для каждого конкретного SingletonData получаем несколько точек входа, но каждая точка входа всегда возвращает один и тот же объект.
Какой в этом практический смысл? Он сиглтон не потому что всегда только один объект возвращает, а потому что предоставляет одну точку доступа к созданию объектов, что позволяет контролировать их количество.

A> А это уже чёрт знает что, а не синглтон.
Это именно сиглтон, а вот множество точек доступа — действительно черт знает что.. =)

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

A>Ээээ здрасьте

Какой смысл устраивать нестолько точек доступа к разным, но однотипным объектам (по точке доступа на объект) я понимаю, а вот какой смысл устраивать round-robin объектов? Ты предлагаешь реализацию в которой Singleton.Instance != Singleton.Instance, а это уже полная бессмыслица.
Может хватит уже? Ибо синглетон сам по себе полная бессмыслица.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

V>В Лиспе ресолвинг имен происходит похожим образом. Таким же образом фиксируются замыкания. Но к теме синглтонов тема создания окружения (environment) из иерархий "областей" (контекстов) не имеет отношения.
Имеет. Такое окружение делает синглетоны не нужными.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

29.10.06 10:23: Перенесено модератором из '.NET' — TK

On Fri, 12 May 2006 08:35:35 +0300, AKoldin <19634@users.rsdn.ru> wrote:

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

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

В static классы удобно складывать какие нить тулзовые ф-ии.
Singleton можно заменять Mock объектом в тестах.

Posted via RSDN NNTP Server 2.0

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

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

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

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

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

Простите, что вмешиваюсь в дискуссию. Как пример управления временем жизни Singleton'а вспоминается Remoting и
Leased Based Manager, хотя может пример и не удачный.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Static-объект не передашь через границу домена — еще один довод в пользу синглтона.

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

_FR>

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

А зачем его передавать как параметр?

Он один и доступен из любого места.

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

_FR>>

_FR>>

В>А зачем его передавать как параметр?

Он один и доступен из любого места.

Например, экземпляр ApplicationContext — синглетон. А передавать его нужно в Application.Run(ApplicationContext context).

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

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

_FR>>>

_FR>>>

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

В>>А зачем его передавать как параметр?

Он один и доступен из любого места.

_FR>Например, экземпляр ApplicationContext — синглетон. А передавать его нужно в Application.Run(ApplicationContext context).
ApplicationContext — не синглтон!

Здравствуйте, Александер Малафеев, Вы писали:

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

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

_FR>>>

В>>А зачем его передавать как параметр?

Он один и доступен из любого места.
АМ>Например для сериализации — передается как параметр.
Ну, если по дизайну сериализуемый объект должен быть синглтоном, то да, лучше использовать классическую имплементацию, а не статики. Я бы пересмотрел в таком случае дизайн. Примером является сам фрэймворк, где классических синглтонов нет, а вот статиков полно. Но это ИМХО уже стилистика основанная на личных предпочтениях

Интересно что сам майкрософт думает по этому поводу.

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

_FR>>>>

_FR>>>>

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

В>>>А зачем его передавать как параметр?

Он один и доступен из любого места.

_FR>>Например, экземпляр ApplicationContext — синглетон. А передавать его нужно в Application.Run(ApplicationContext context).
В>ApplicationContext — не синглтон!

Да ты что!

using System;
using System.Windows.Forms;

namespace WindowsApplication1
{
  internal partial class MyForm : Form
  {
    public MyForm()
    {
    }
  }

  internal class AppContext : ApplicationContext
  {
    public static readonly AppContext Instance = new AppContext();

    private AppContext()
    {
      MainForm = new MyForm();
    }
  }

  static class Program
  {
    [STAThread]
    static void Main()
    {
      Application.Run(AppContext.Instance);
    }
  }
}

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

В>Здравствуйте, Александер Малафеев, Вы писали:

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

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

_FR>>>>

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

В>>>А зачем его передавать как параметр?

Он один и доступен из любого места.
АМ>>Например для сериализации — передается как параметр.
В>Ну, если по дизайну сериализуемый объект должен быть синглтоном, то да, лучше использовать классическую имплементацию, а не статики. Я бы пересмотрел в таком случае дизайн. Примером является сам фрэймворк, где классических синглтонов нет, а вот статиков полно. Но это ИМХО уже стилистика основанная на личных предпочтениях

В>Интересно что сам майкрософт думает по этому поводу.
Ну по моему майкрософт по этому поводу вообще мало думает

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

Здравствуйте, Александер Малафеев, Вы писали:

АМ>Ну по моему майкрософт по этому поводу вообще мало думает

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

_FR>Здравствуйте, Александер Малафеев, Вы писали:

АМ>>Ну по моему майкрософт по этому поводу вообще мало думает

Например, чтобы отключить валидацию сертификатов при работе WebClient по https, нужно написать следующий код:

  internal class AcceptAllCertificatePolicy: System.Net.ICertificatePolicy
  {
    
    public bool CheckValidationResult(
      ServicePoint srvPoint,
      X509Certificate certificate,
      WebRequest request,
      int certificateProblem
      )
    {
      return true;
    }
  }

И в статическом классе ServicePointManager установить CertificatePolicy:

ServicePointManager.CertificatePolicy = new AcceptAllCertificatePolicy();
// дальше работаем с WebClient
System.Net.WebClient client = new System.Net.WebClient();

Хотя более логичным отнаследоваться от WebClient и переопределить какой нибуть метод типа CheckValidationResult.
Или надо было сделать синглтон(если им уж так хочется) и возвращать ссылку на него из WebClient'a.
Что нибуть в стиле:

client.ServicePointManager.CertificatePolicy = new AcceptAllCertificatePolicy();

А так получился далеко не очевидный код и типичный пример "антипаттерна" синглтон.

Здравствуйте, Александер Малафеев, Вы писали:

АМ>А так получился далеко не очевидный код и типичный пример "антипаттерна" синглтон.

Сталкивался с чем то подобным в Remoting. Тут проблема не в том что используют статики вместо классического синглтона (разницы никакой), а в том что есть трудно прослеживаемая связь между ServicePointManager и WebClient.

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

В>Здравствуйте, Александер Малафеев, Вы писали:

АМ>>А так получился далеко не очевидный код и типичный пример "антипаттерна" синглтон.

В>Сталкивался с чем то подобным в Remoting. Тут проблема не в том что используют статики вместо классического синглтона (разницы никакой), а в том что есть трудно прослеживаемая связь между ServicePointManager и WebClient.

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

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

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

А сами контексты уж не синглетоны-ли?

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

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

_FR>А сами контексты уж не синглетоны-ли?

Нет.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

MF>Static-объект не передашь через границу домена — еще один довод в пользу синглтона.

Вообще-то если функции объявлены как public, то — очень даже

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

WH>Допустим ...
Идея интересная, надо обдумать. Это ты сам придумал, или где вычитал?

Можно ссылку?

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

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

В>>А можно по подробней?

Тогда, все сервисы каждого из компонентов должны быть документированы (что бы знать на каком уровне что находится — понадобится разработчикам сервисов)?

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

_FR>Тогда, все сервисы каждого из компонентов должны быть документированы (что бы знать на каком уровне что находится — понадобится разработчикам сервисов)?
А в чем проблема?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

В>Идея интересная, надо обдумать. Это ты сам придумал, или где вычитал?

Можно ссылку?
Я работал над проектом в котором такая система использована.

В>Менеджер зоопарка не должен быть одиночкой?
Кокой менеджер?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

_FR>>Тогда, все сервисы каждого из компонентов должны быть документированы (что бы знать на каком уровне что находится — понадобится разработчикам сервисов)?
WH>А в чем проблема?

Если это так, то зачем унифицированный доступ? Почему нельзя сделать сервисы открытыми свойствами?

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

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

В>>Идея интересная, надо обдумать. Это ты сам придумал, или где вычитал?

Можно ссылку?
WH>Я работал над проектом в котором такая система использована.

В>>Менеджер зоопарка не должен быть одиночкой?
WH>Кокой менеджер?

Наверно я плохо понял пример.
Имеется ввиду Dependency Injection?

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

А как осуществляется доступ к экземпляру такого констекста? Мне кажется этот паттерн несколько ортогонален синглетону...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

_FR>>Если это так, то зачем унифицированный доступ? Почему нельзя сделать сервисы открытыми свойствами?
WH>И при появлении каждого нового сервиса протаптывать его во всех контекстах? А не озвереешь?

Нет, как раз не "протаптывать", а обращаться к тому, какой нужен, раз уж они заранее известны. Просто в приведённой реализации пропадает самая соль "ServiceProvider`а", которая, имхо, в том, что типы (параметра GetService(…) и экземпляра) должны сравниваться не на равенство, а на реализацию, примерно так:

using System;
using System.Diagnostics;

namespace ConsoleApplication2
{
  interface IGenericServiceProvider : IServiceProvider
  {
    T GetService<T>() where T : class;
  }

  interface IService1
  {
  }

  interface IService2
  {
  }

  interface IService3
  {
  }

  interface IService4 : IService1
  {
  }

  class Service14 : IService1, IService4
  {
  }

  class Service23 : IService2, IService3
  {
  }

  class SomeContext : IGenericServiceProvider
  {
    Service14 service14 = new Service14();
    Service23 service23 = new Service23();
    IServiceProvider externalService = null;

    public object GetService(Type serviceType)
    {
      object service;
      if(FindService(service14, serviceType, out service) 
        || FindService(service23, serviceType, out service)
        || FindServiceFromProvider(externalService, serviceType, out service)
      ) {
        return service;
      }//if

      return null;
    }

    public T GetService<T>() where T : class
    {
      return (T)GetService(typeof(T));
    }

    private bool FindService(object service, Type serviceType, out object instance)
    {
      if(service == null)
      {
        throw new ArgumentNullException("service");
      }//if

      return (instance = serviceType.IsAssignableFrom(service.GetType()) ? service : null) != null;
    }

    private bool FindServiceFromProvider(IServiceProvider service, Type serviceType, out object instance)
    {
      if(service == null)
      {
        throw new ArgumentNullException("service");
      }//if

      return (instance = service.GetService(serviceType)) != null;
    }
  }

  class Program
  {
    static void Main(string[] args)
    {
      IGenericServiceProvider provider = new SomeContext();
      IService1 service1 = provider.GetService<IService1>();
      IService2 service2 = provider.GetService<IService2>();
      IService3 service3 = provider.GetService<IService3>();
      IService4 service4 = provider.GetService<IService4>();
    }
  }
}

IGenericServiceProvider тут для простоты доступа "из-вне": позволяет указывать имя типа сервиса на один раз меньше.

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

ВВ>А как осуществляется доступ к экземпляру такого констекста?
Контекст передают либо при вызове метода либо в конструктор объекта.

ВВ>Мне кажется этот паттерн несколько ортогонален синглетону...
Он делает синглитон в его классической реализации не нужным.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

_FR>Нет, как раз не "протаптывать", а обращаться к тому, какой нужен, раз уж они заранее известны. Просто в приведённой реализации пропадает самая соль "ServiceProvider`а", которая, имхо, в том, что типы (параметра GetService(…) и экземпляра) должны сравниваться не на равенство, а на реализацию, примерно так:
То что ты написал это детали реализации которая может быть сколь угодно наворочена. Ничего принципиально они не меняют.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

ВВ>Может я чего-то и не догоняю, но в том что ты описал я не увидел особого отличия от паттерна Service Layer. И сделать сервис-провайдер синглетоном вполне может оказаться куда более удобным чем передача его экземпляра. Т.е. во всем что ты описал — аналог собственно синглтона это та самая "передача экмзепляра", которую вполне и без сервис лаера можно использовать и считать это чем-то более продвинутым чем синглетон мне кажется несколько затруднительным.
Правда? А может ты мне объяснишь как сделать на синглетоне то что я описал.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Зачем IComponent'у IDisposable?
Думаю что бы выбросить самого себя из site. Как я понимаю компонент можно добавить в контейнер его собственного сайта как делается в Dependency Injection, и тогда нужно удалять себя оттуда перед тем как удалиться.

public class Component : MarshalByRefObject, IComponent, IDisposable
{
...
public void Dispose()
{
      this.Dispose(true);
      GC.SuppressFinalize(this);
}

protected virtual void Dispose(bool disposing)
{
      if (disposing)
      {
            lock (this)
            {
                  if ((this.site != null) && (this.site.Container != null))
                  {
                        this.site.Container.Remove(this);
                  }
...
            }
      }
}


...
}

WH>Зачем ISite'у Name и DesignMode?
Понятия не имею

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

_FR>>Нет, как раз не "протаптывать", а обращаться к тому, какой нужен, раз уж они заранее известны. Просто в приведённой реализации пропадает самая соль "ServiceProvider`а", которая, имхо, в том, что типы (параметра GetService(…) и экземпляра) должны сравниваться не на равенство, а на реализацию, примерно так:
WH>То что ты написал это детали реализации которая может быть сколь угодно наворочена. Ничего принципиально они не меняют.

Точно. Увлёкся :о) Попробую ближе к теме:

При использовании такого подхода удалось ли Вам полностью избавиться от синглетонов? Если синглетоны всё же были, то по каким признакам класс попадал в разряд сервисов или "одиночек"?

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

WH>Правда? А может ты мне объяснишь как сделать на синглетоне то что я описал.

То, что написал ты, как раз можно, поскольку набор сервисов заранее известен, дело только за "протаптывать его во всех контекстах". И, в принципе, не всегда можно добавить "лишний параметр метода или конструктора"

Но мне предложенная тобой идея тоже сильно понравилась

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

WH>>Зачем IComponent'у IDisposable?
В>Думаю что бы выбросить самого себя из site. Как я понимаю компонент можно добавить в контейнер его собственного сайта как делается в Dependency Injection, и тогда нужно удалять себя оттуда перед тем как удалиться.
А если компонент не управляет собственной судьбой? Например еонтейнер сам по запросу сканирует лежащие в нем компоненты и по определенным признакам выкидывает?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

_FR>То, что написал ты, как раз можно, поскольку набор сервисов заранее известен, дело только за "протаптывать его во всех контекстах".
Как сделать так чтобы на корне могло быть несколько сессий? В каждой сессии могло быть несколько отображений? При этом у каждой сессии и отображения должна быть своя копия сервисов.

_FR>И, в принципе, не всегда можно добавить "лишний параметр метода или конструктора"

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

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Правда? А может ты мне объяснишь как сделать на синглетоне то что я описал.

Сделать сервис-провайдер синглетоном?

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

WH>>Правда? А может ты мне объяснишь как сделать на синглетоне то что я описал.
ВВ>Сделать сервис-провайдер синглетоном?
И? Как ты для каждой сессии заведешь свою копию сервисов уровня сессии?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

ВВ>Гм, тебе не кажется что это уже другой вопрос и к синглетону как таковому отношения не имеет? Все что я хотел сказать — это то что сервис провайдер как таковой никак не противоречит синглетону ни в классическом его смысле, ни в неклассическом (см. например ремотинг, куда этот паттерн прекрасно подходит).
Нет не кажется. Как ты думаешь почему я и не только я послал синглитоны в лес?
Просто по тому что они очень сильно связывают программу, а сильная связанность ничего кроме гемороя не дает.
Например смотри мое сообщение как ты думаешь если бы логер сделали синглитоном (что очень часто с ним и делают) то можно было бы также легко добавить информацию о сессии в контексте которой происходит запись в лог?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

ВВ>Т.е. то что ты предлагаешь — это универсальное решение, которое всегда можно и нужно использовать вместо синглетонов? В противном случае я не понимаю, о чем спор.
Именно.

ВВ>Прекрасно. Никто же не говорит, что нужно всегда использовать синглтоны. Приводить примеры где синглтон будет кстати? Просто ты привел решение, которое никак не заменяет и вообще полностью перпендикулярно синглтонам.
Попробуй.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

ВВ>Да все очень просто — требуется глобальный инстанс в домене (или даже не только в домене) приложения.
Эта модель не препятствует сервису быть в одном экземпляре.
ВВ>Примеры — файл конфига,
Допустим мы пишем IDE... на каждый проект по проектному файлу...
А если программа поддерживает несколько пользователей? А если эти пользователи могут быть залогинины одновременно?
Так сколько у нас конфигов?
ВВ>глобальный сервис провайдер (например, в случае если этот паттерн используется при работе с плагинами),
Ну да конечно, а про то что у нас в разных проектах разные языки программирования и им нужен разный интелисенс мы и забыли.
ВВ>сервис ремотинг,
С ним дел не имел.
ВВ>фасад слоя доступа к данным и пр.
Вот ведь как нехорошо то получается... некоторые сесии хотят чтобы обращения к базе логировались... другие хотят блокировать некоторые запросы которые идут от бизнес логики, а третьи сессии вот ведь гады какие полезли в другую базу...

ВВ>Как только мы попробуем сущности, изначально расчитанные на "общий" доступ, передвать каким-либо образом вместо того, чтобы делать их статиками/синглетонами, то свяжем весь остальной код не меньше, обязав его следовать определенному контракту — реализовывать специальным образом конструктор или определять специальный метод — что тоже особенно не весело.
Тут два варианта
1)Использовать синглетоны и статики:
+Меньши возьни в тривиальных случаях.
-Вешалка в нетривиальных случаях.
2)Использовать то что я описал:
-Больше возьни в тривиальных случаях.
+Можно разрулить большинство нетривиальных случаев не напрягаясь.

Не знаю как у тебя, а у меня встречаются все больше нетривиальные случаи. К томуже если мы уж начали использовать такую схему то она в любом случае прошьет всю программу... и тогда уж точно не будет никакого смысла использовать синглетоны.

Итого: Никаких принципиальный преймущест синглитонов ты так и не продемонстрировал.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

_FR>>то по каким признакам класс попадал в разряд сервисов или "одиночек"?
WH>По глупости.
Имеется в виду в разряд "одиночек" по глупости.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

ВВ>А вот если нет таких сессий? И приложение однопользовательское — или уж, во всяком случае, не допускает несколько одновременно залогиненных пользователей? И что-то мне сдается, что это куда более распространенный вариант, чем ты описываешь.
Не будет сессий будет что-то другое что без такой механики делаль задолбаешься. А если уж завели эту механику то...
ВВ>Ни разу кстати не писал локальный дата-лаер с которым работает одновременно несколько различных сессий с разными требованиями к фунцкиональности.
А у меня было. И кто сказал что это обязательно должен быть клиент? Может это сервер?

ВВ>А у меня — наоборот — больше тривиальные. В итоге — нашли ли мы silver bullet?
Их как извесно не бывает. Вот только я предпочитаю ходить с пистолетом даже если в нем обыкновенные пули нежели с дубинкой.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

_FR>>То, что написал ты, как раз можно, поскольку набор сервисов заранее известен, дело только за "протаптывать его во всех контекстах".
WH>Как сделать так чтобы на корне могло быть несколько сессий? В каждой сессии могло быть несколько отображений? При этом у каждой сессии и отображения должна быть своя копия сервисов.

Да, например, синглетоном иметь словарь — сессия — что-то ещё

Ну это и впрямь не так важно.

_FR>>И, в принципе, не всегда можно добавить "лишний параметр метода или конструктора"

WH>Просто проектировать нужно в расчете на это.

Мне очень понравилось то, как это сделано через ObjectBuilder в EnterprizeLibrary — никаких лишних параметров, только открытые свойства, аттрибуты которых говорят о том, что в них нужно записать при построении объекта.

WH>Кстати Варвар дал хорошую ссылку в этом сообщении. ИМХО неплохое чтиво хотя я и не со всем согласен.

Конечно.

Но мне во всём этом не нравится только одно — необходимость проверки возвращённого GetService(…) значения на null

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

_FR>Да, например, синглетоном иметь словарь — сессия — что-то ещё

Ну это и впрямь не так важно.
Не реентернабельно. Да и геморой это стращный.

_FR>Но мне во всём этом не нравится только одно — необходимость проверки возвращённого GetService(…) значения на null

Ты же тут ввел 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>>

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

_FR>>Да, например, синглетоном иметь словарь — сессия — что-то ещё

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

_FR>>Но мне во всём этом не нравится только одно — необходимость проверки возвращённого GetService(…) значения на null

WH>Ты же тут ввел IGenericServiceProvider ну и запиши ему в контракт что в случае отсутствия сервиса вылетает исключение.

Боюсь, это должно зависеть от самого сервиса — обязательный он, или нет. Например, есть IMessageService, отвечающий за вывод пользователю некоей информации — он дожен быть всегда: в самом крайнем случае выводить в файл. А, например, IDebugService имеет право отсутствовать. Но да, это всё можно решить внутри GetService.

... << RSDN@Home 1.2.0 alpha rev. 650>>
Now playing: «Тихо в лесу…»

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

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

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

Конечно модель спроектированная MS не только для дизайнера применима.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

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

Смешно.

По сравнению с генерацией html это просто ничто.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

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

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

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

Смешно.

WH>По сравнению с генерацией html это просто ничто.

Контексты разные бывают.
Хотя в принципе можно делать, иницилизацию по требованию разных сервисов.
У нас есть много синглетонов, инизиализация которых ресурсоёмкая операция, они содержат достаточно много словарей и много разного ещё, загруженного из базы данных. Как Вы в подобных случаях поступаете.

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

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

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

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

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

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

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

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

Если этого ничего не надо, то static class вполне подходит.

Здравствуйте, 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>>

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

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

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

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

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

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

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

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

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

Оно и есть.

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

Упоминание про C# было в связи с тем, что, как и в C++,, статические функции-члены не могут быть виртуальными.

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

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

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

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

— иногда полезно, но редко

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

A>Если этого ничего не надо, то static class вполне подходит.
согласен

AK>>Эта проблема для шарпа не актуальна (с его вызовом статик конструктора), как это есть для с++, по которому в основном и строились паттерны
A>Как же не актуальны? Например, берем класс, предоставляющий доступ к DataSet-у. В конструкторе, нам необходимо проинициализировать этот DataSet. С синглетоном все понятно, а вот со статик классом как быть?
A>Его конструктор вообще может быть вызван ДО входа в функцию Main, как это описано здесь.

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

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

А>Здравствуйте, 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 бизнес модель, реализованную в виде синглтона. Представьте, пожалуйста, этот синглтон в виде сервиса.

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

По тому что делает синглутон не нужным и за одно избавляет от кучи проблем.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

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

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

Паттерн Singlton
Название и классификация паттерна
Одиночка — паттерн, порождающий объекты.
Назначение
Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа.

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

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, 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 и там этой особенности синглтона было уделено особое внимание.
Синглтон — это именно контролирумое число экземпляров, а не один и только один экземпляр, нет ни одной причины, чтобы не использовать этот паттерн в данном качестве.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

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

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

A>По моему это ты что-то не так прочитал.
Ага, в нескольких источниках.. ) И голову тоже, совсем отключил.. ) Не поленился, нашел и оригинал и перевод. Действительно немного прогнал насчет определения, но в описании все очень недвусмыслено сказано.

A> Там написано, что может быть несколько точек доступа для одного и того же класса,
A> но ничего не сказано о том, что за одной точкой доступа может скрыватся несколько объектов.
Супер! Вообщем, выкидывай свой экземпляр. =)

Русская версия, раздел достоинства паттерна:

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

Английский оригинал:

Permits a variable number of instances. The pattern makes it easy to change your mind and allow more than one instance of the Singleton class. Moreover, you can use the same approach to control the number of instances that the application uses.

У Влиссидеса же, прямо в определении сказано, что это паттерн контролирования числа экземпляров, а не ограничивания исключительно одним, что логичнее.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

IB>Русская версия, раздел достоинства паттерна:
IB>

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

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

IB>У Влиссидеса же, прямо в определении сказано, что это паттерн контролирования числа экземпляров, а не ограничивания исключительно одним, что логичнее.

Не читал. Но ИМХО и не имеет смысла, так как мы с тобой умудряемся один и тот же текст читать по-разному.

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

IB>

Поясняю. Вот как класс описан в книге.

class Singleton {
public:
    static Singleton* Instance();
protected:
    Singleton();
private:
    static Singleton* _instance;
}

и определенение

Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
    if (_instance == 0) {
        _instance = new Singleton();
    }

    return _instance;
}

Это очень плохое описание, так как оно позволяет трактовать по-разному цитату выше. Более того в развитых языках типа C# или C++ оно никогда в таком виде не используется (потому что шаблоны и дженерики). Давай его уточним разделив на те две сущности, которые обычно присутствуют.

class SingletonManager {
public:
    static SingletonData* Instance();
private:
    static SingletonData* _instance;
}

Я говорю о том что в цитате выше говорится о множественных глобальных точках входа. Они могут быть реализоваты так

class SingletonManager {
public:
    static SingletonData* Instance(int index);
}

либо так

class SingletonManager {
public:
    static SingletonData* Instance1();
    static SingletonData* Instance2();
}

либо так (пожалуй наиболее ввероятный случай)

class SingletonManager1 {
public:
    static SingletonData* Instance();
}
class SingletonManager2 {
public:
    static SingletonData* Instance();
}

В любом случае для каждого конкретного SingletonData получаем несколько точек входа, но каждая точка входа всегда возвращает один и тот же объект.

Насколько же я понял тебя, ты утверждаешь, что у класса

class SingletonManager {
public:
    static SingletonData* Instance();
}

метод SingletonManager::Instance() может возвращать разные объекты. А это уже чёрт знает что, а не синглтон.

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

IB>Цитату выше нельзя трактовать по разному. Английское слово instance переводится на русский как экземпляр. Множество экземпляров синглтона означает именно множество экземпляров, а не множество способов добраться до одного экземпляра.

Множество экземпляров которого синглтона? SingletonManager или SingletonData? Неоднозначность, которую ты почему-то пытаешься разрешись самым неочевидным способом.

IB>В цитате выше нет ни слова о глобальных точках входа. Зато там несколько раз упоминается слово экземпляр, как это еще до тебя донести?

Как ещё до тебя донести, что там речь о SingletonManager, а не SingletonData?

IB>Какой в этом практический смысл? Он сиглтон не потому что всегда только один объект возвращает, а потому что предоставляет одну точку доступа к созданию объектов, что позволяет контролировать их количество.

Ээээ здрасьте

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

A>Множество экземпляров которого синглтона?
Синглтон один.

A> SingletonManager или SingletonData? Неоднозначность, которую ты почему-то пытаешься разрешись самым неочевидным способом.
Здесь нет никакой неоднозначности.

A>Как ещё до тебя донести, что там речь о SingletonManager, а не SingletonData?
Во-первых, нет никакого Manager и Data, ты никогда его не писал что ли?
А во-вторых, даже в твоей реализации Manager все равно один, так о каких экземплярах речь?

A>Ээээ здрасьте

Здрасте.

A> Какой смысл устраивать нестолько точек доступа
Вот и я спрашиваю, какой смысл устраивать несколько точек доступа? Приведи практический пример, когда понадобится к одному объекту иметь несколько точек доступа (то что предлагаешь ты).

A>к разным, но однотипным объектам (по точке доступа на объект)
Это как?

A>Ты предлагаешь реализацию в которой Singleton.Instance != Singleton.Instance, а это уже полная бессмыслица.
Ну, если тебе смысл не ясен, это не значит что надо коверкать определение и пытаться придать ему какой-то третий смысл. В определении сказано все четко, что по русски, что по английски.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

A>>Множество экземпляров которого синглтона?
IB>Синглтон один.

Это моя фраза

A>> SingletonManager или SingletonData? Неоднозначность, которую ты почему-то пытаешься разрешись самым неочевидным способом.
IB>Здесь нет никакой неоднозначности.

Вернее тебе очень невыгодно её видеть.

A>> Какой смысл устраивать нестолько точек доступа
IB>Вот и я спрашиваю, какой смысл устраивать несколько точек доступа? Приведи практический пример, когда понадобится к одному объекту иметь несколько точек доступа (то что предлагаешь ты).
A>>к разным, но однотипным объектам (по точке доступа на объект)
IB>Это как?

Это, например, вот так.

template<typename TData, int IData>
class Singleton
{
  private:
    static TData _instance;
  public:
    TData & Instance()
    {
      return _instance;
    }
}

// точка доступа
Singleton<Type, 0>::Instance()
// другая точка доступа
Singleton<Type, 1>::Instance()

Обе точки доступа возвращают разные объекты, но каждая всегда один и тот же (каждая свой). Причём возвращаемые объекты имеют один и тот же тип.
Можно чуть сложнее, используя std::map и перенеся выбор точки в из compile-time в run-time. Реальный пример использования? Вот у меня сейчас выплыло окно ICQ, так что навеяно. Сделаем такой класс для параметров пользователя ICQ

class IcqUserSettingsAccessor
{
  public:
    IcqUserSettings & GetInstance(int icqUserID);
}

Параметры каждого пользователя присутствуют всего в одном экземпляре (синглтон), однотипны, но всего пользователей много (множественные точки доступа).

IB>Ну, если тебе смысл не ясен, это не значит что надо коверкать определение и пытаться придать ему какой-то третий смысл.

Смысл коверкаешь исключительно ты. А я жду практический пример использования "твоего синглтона".

IB>В определении сказано все четко, что по русски, что по английски.

Видимо нет, раз ты такие странные вещи утверждаешь.

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

A>Это моя фраза

Тогда где ты там два нашел?

A>Вернее тебе очень невыгодно её видеть.
Чем?

Ты из синглтона, паттерна для одного класса, сделал два класса, нарушив тем самым закрытость создания экземпляра, откопал в этом неоднозначность и обвиняешь меня в том, что это неудобно! Умница.. =)

A>Это, например, вот так.
Так не пойдет. Из внешнего кода всегда можно создать new Type() — и привет, у тебя завелся еще один неконтролируемый экземпляр.
Синглтон же не позволяет создавать объекты в обход своего GetInstance.

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

A>Параметры каждого пользователя присутствуют всего в одном экземпляре (синглтон), однотипны, но всего пользователей много (множественные точки доступа).

То есть на каждого пользователя своя "точка доступа"? Зашибись идея

При этом каждый пользователь должен знать к какой точке обращаться?

Best, Рома, это пять..

Это не точки доступа, это как раз разные экземпляры одного синглтона, по экземпляру на каждого пользователя. Еще раз: один синглтон, для каждого пользователя. Возвращаются они через один метод instance(), возможно с параметром позволяющим пользователя идентифицировать но это все равно одна точка доступа, она глобальна. Других точек доступа нет, но на каждого пользователя возвращается свой экземпляр и этих экземпляров будет не один, а ровно столько сколько пользователей.
Так понятнее?

A>Смысл коверкаешь исключительно ты.
Перечитай еще раз определение, внимательно. Напоминаю: "Его можно использовать для управления количеством экземпляров, используемых определенным приложением, требуется только изменить операцию Instance, которая предоставляет доступ к экземпляру класса Singleton"
Обрати внимание, не добавить новый Instance, а изменить(!) это именно тот Instance, который предоставляет доступ к экземпляру класса Singleton (SinglrtonData в твоей терминологии). Осознал?

A>А я жду практический пример использования "твоего синглтона".
Да сколько угодно. Например, всевозможные пулы объектов, механизмы разгребания очередей и прочий многопоточный хлам, те же юзера при сетевой обработке, когда надо добиться чтобы работало строго заданное количество объектов, но явно больше одного.
Сужая количество экземпляров до одного ты здорово ограничиваешь возможности паттерна.

A>Видимо нет, раз ты такие странные вещи утверждаешь.
Я странные вещи утверждаю? Ты себя-то читал?

... [RSDN@Home 1.2.0 alpha rev. 619]

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

WH>Может хватит уже? Ибо синглетон сам по себе полная бессмыслица.
Не руби с плеча..

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

... [RSDN@Home 1.2.0 alpha rev. 619]

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

A>>Это, например, вот так.
IB>Так не пойдет. Из внешнего кода всегда можно создать new Type() — и привет, у тебя завелся еще один неконтролируемый экземпляр.
IB>Синглтон же не позволяет создавать объекты в обход своего GetInstance.

, а friend для чего по твоему создан? Я просто не стал загромождать пример кода всяким техническим хламом, а ты поспешил найти "ошибку". Скучно, просто, скучно отвечать на такие неквалифицированные замечания не имеющие никакого отношения к сути вопроса.

IB>Это будет просто фабрика объектов, да, все объекты создаваемые через эту фабрику будут контролироваться, но ничто не помешает создать объект в обход этой фабрики.

Фабрика объектов это совсем другая вешь.

IB>Это не точки доступа, это как раз разные экземпляры одного синглтона, по экземпляру на каждого пользователя. Еще раз: один синглтон, для каждого пользователя. Возвращаются они через один метод instance(), возможно с параметром позволяющим пользователя идентифицировать но это все равно одна точка доступа, она глобальна.

Если есть параметр, то это уже не одна точка доступа.

IB>Так понятнее?

Мне и так всё ясно, это ты не понял простейший пример со списком контактов ICQ.

IB>Перечитай еще раз определение, внимательно. Напоминаю: "Его можно использовать для управления количеством экземпляров, используемых определенным приложением, требуется только изменить операцию Instance, которая предоставляет доступ к экземпляру класса Singleton"

Ты просто не понимаешь смысла этой фразы, зачем ты мне её пишешь?

IB>Обрати внимание, не добавить новый Instance, а изменить(!) это именно тот Instance, который предоставляет доступ к экземпляру класса Singleton (SinglrtonData в твоей терминологии). Осознал?

В данном случае никакой разницы между добавить и изменить нет.

IB>Да сколько угодно. Например, всевозможные пулы объектов, механизмы разгребания очередей и прочий многопоточный хлам, те же юзера при сетевой обработке, когда надо добиться чтобы работало строго заданное количество объектов, но явно больше одного.

И это ты решаешь синглтоном, Instance() которого возвращает разные объекты?! Зашибись!

IB>Сужая количество экземпляров до одного ты здорово ограничиваешь возможности паттерна.

IB>Я странные вещи утверждаю? Ты себя-то читал?

Взаимно.

Дискуссию прекращаю, ибо не интересно.

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

A> а friend для чего по твоему создан?
Сюрпрайз, friend есть не везде.

A>Я просто не стал загромождать пример кода всяким техническим хламом, а ты поспешил найти "ошибку".
Без этого хлама паттерн не полноценен — ты всегда недоделанные решения поставляешь? Ты без нужды очень сильно усложнил паттерн введя лишние сущности, при этом не позаботившись их правильно связать.

A> Скучно, просто, скучно отвечать на такие неквалифицированные замечания не имеющие никакого отношения к сути вопроса.
Ну да, от неудобных замечаний мы будем отмахиваться, называя их неквалифицированными..

A>Фабрика объектов это совсем другая вешь.
Поговорим теперь о фабриках..

A>Если есть параметр, то это уже не одна точка доступа.
Рома, два раза пять.

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

A>Мне и так всё ясно, это ты не понял простейший пример со списком контактов ICQ.
Нет, это ты не смог его объяснить..

Давай ты возьмешь C# и напишешь синглтон, который выдает класс настроек для каждого пользователя и мы посмотрим, где там экземпляры и где там точки доступа.

A>Ты просто не понимаешь смысла этой фразы,
Какой ты еще там видишь смысл, кроме возможности наличия нескольких экземпляров у синглтона?

A>зачем ты мне её пишешь?
Чтобы донести ее смысл до тебя..

A>И это ты решаешь синглтоном, Instance() которого возвращает разные объекты?!
Это не я считаю, это паттерн такой.

A>Дискуссию прекращаю, ибо не интересно.
Ну правильно, осознал свои заблуждения?

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

A>> а friend для чего по твоему создан?
IB>Сюрпрайз, friend есть не везде.

Убогость языка программирования это не недостаток паттерна. На Си вообще нет ни классов, ни спецификаторов доступа, что же теперь все паттерны отменять?

IB>Без этого хлама паттерн не полноценен

Ты опять твои фантазии выдаёшь за истину.

A>>Фабрика объектов это совсем другая вешь.
IB>Поговорим теперь о фабриках..

Зачем? Ты одну главу-то книги не осилил.

IB>Рома, два раза пять.

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

Один метод != одна точка доступа.

IB>Нет, это ты не смог его объяснить..

Давай ты возьмешь C# и напишешь синглтон, который выдает класс настроек для каждого пользователя и мы посмотрим, где там экземпляры и где там точки доступа.

То есть твой единственный аргумент это "В C# нету friend"? Это не мои проблемы и не проблемы паттерна, это проблемы C#. Чего сразу Си не предложить?Там мно-о-ого чего нет.

IB>Какой ты еще там видишь смысл, кроме возможности наличия нескольких экземпляров у синглтона?

Возможность нескольких экземпляров — да. Этого никто и не оспаривает. Речь идёт о способе доступа к ним.

A>>И это ты решаешь синглтоном, Instance() которого возвращает разные объекты?!
IB>Это не я считаю, это паттерн такой.

Только в твоём понимании.

A>>Дискуссию прекращаю, ибо не интересно.
IB>Ну правильно, осознал свои заблуждения?

Да нет, просто лень что-то доказывать упрямцу вроде тебя.

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

A>Убогость языка программирования это не недостаток паттерна.
А кто здесь говорит про недостатки паттерна? Я говорю про недостатки твоей реализации, и уж очевидно язык тут непричем, так как данный паттерн отлично на C# реализуется, если его не коверкать предложенным тобой способом.

A> На Си вообще нет ни классов, ни спецификаторов доступа, что же теперь все паттерны отменять?
Не передергивай, не умеешь..

A>Ты опять твои фантазии выдаёшь за истину.
Рома, ты неоправдано усложнил паттерн и дал незаконченное решение, какие фантазии?

A>Зачем? Ты одну главу-то книги не осилил.
Рома, не хами, в последний раз предупреждаю.

A>Один метод != одна точка доступа.
Я правильно понимаю, что в твоей терминологии Instance(Int16 i) означает 65535 "точек доступа"?

Последняя попытка, призываю тебя все-таки взглянуть на описание паттерна и понять, что там везде говорится про доступ через одну(!) глобальную well-known access point и возможность контролировать через эту access point количество экземпляров, не ограничиваясь одним, если того требуют интересы дела. Но ни как не наоборот (обеспечивать доступ через множество точек доступа к одному единственному экземпляру)

Сдается мне что у тебя все-таки проблемы с терминологией...

A> Это не мои проблемы и не проблемы паттерна, это проблемы C#.
У C# в данном случае проблем нет, там эта задача реализуется в лет, но я хочу видеть как это сделаешь ты, чтобы понять что ты имеешь ввиду под "точками доступа".

A>Возможность нескольких экземпляров — да.
Ура!

A> Этого никто и не оспаривает.
"У синглота всего одна задача — обеспечить количество экземпляров объекта от 0 до 1." (c) adonz — Бес попутал?

A> Речь идёт о способе доступа к ним.
Способ доступа к ним через один единственный Instance(...) aka well-known access point.

A>Да нет, просто лень что-то доказывать упрямцу вроде тебя.
То есть, продолжаешь упорствовать в своих заблуждениях... И кто после этого упрямец?

... << RSDN@Home 1.2.0 alpha rev. 0>>

	От:	WolfHound
	Дата:	16.05.06 11:28
	Оценка:	65 (14)

	От:	Воронков Василий
	Дата:	17.05.06 16:19
	Оценка:	6 (1) +1

	От:	WolfHound
	Дата:	24.10.06 16:54
	Оценка:	+3

	От:	Воронков Василий
	Дата:	17.05.06 19:51
	Оценка:	3 (1) +1

	От:	mrozov
	Дата:	12.05.06 13:09
	Оценка:	1 (1) +1

От:	Александер Малафеев	http://www.meet-tech.com
Дата:	12.05.06 13:22
Оценка:	1 (1) +1

	От:	Варвар
	Дата:	17.05.06 21:03
	Оценка:	1 (1) +1

От:	IB	http://rsdn.ru
Дата:	30.10.06 08:29
Оценка:	+2

От:	_FRED_	@ViIvanov
Дата:	12.05.06 06:36
Оценка:	+1

От:	adontz	http://adontz.wordpress.com/
Дата:	29.10.06 02:58
Оценка:	+1

	От:	IDL
	Дата:	20.05.06 16:02
	Оценка:	-1

	От:	Аноним
	Дата:	21.05.06 19:16
	Оценка:	+1

	От:	SerkMan
	Дата:	18.05.06 14:45
	Оценка:	+1

	От:	Аноним
	Дата:	21.05.06 17:29
	Оценка: