Я понимаю, что тема возможно избита, но все же у кого какие мысли?
Есть критерии использования этого паттерна, которые выверены на практике.
Только не надо копировать описание синопсиса этого паттерна из "Розовой книжки по Java".
Это будет лишнее =)

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

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

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

MS>Я понимаю, что тема возможно избита, но все же у кого какие мысли?
Итого дискуссий по синглтону:

"главная проблема синглтона в том, что это первый паттерн описанный в GoF" (c) MaximVK. На него набрасываются и не замечают его недостатков, из коих:

1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров.
2. Глобальное состояние. Про вред глобальных переменных вроде бы уже все знают, но тут та же самая проблема. Когда мы получаем доступ к экземпляру класса, мы не знаем текущее состояние этого класса, и кто и когда его менял, и это состояние может быть вовсе не таким, как ожидается. Иными словами, корректность работы с синглтоном зависит от порядка обращений к нему, что вызывает неявную зависимость подсистем друг от друга и, как следствие, серьезно усложняет разработку.
3. Зависимость обычного класса от синглтона не видна в публичном контракте класса. Так как обычно экземпляр синглтона не передается в параметрах метода, а получается напрямую, через GetInstance(), то для выявления зависимости класса от синглтона надо залезть в тело каждого метода — просто просмотреть публичный контракт объекта недостаточно.
4. Наличие синглтона понижает тестируемость приложения в целом и классов, которые используют синглтон, в частности. Во-первых, вместо синглтона нельзя подпихнуть Mock-объект, а во-вторых, если синглтон имеет интерфейс для изменения своего состояния, то тесты начинают зависеть друг от друга.
Говоря же проще — синглтон повышает связность, и все вышеперечисленное, в том или ином виде, есть следствие повышения связности.

Естественно, можно акккуратненько пройти по граблям и использовать синглетон, но (цитата из доки к пикоконтейнеру) "Overuse makes for bad solutions. At the enterprise level, it makes for very very bad solutions"...
Тем более, что при тщательном рассмотрении вопроса, использования синглтона, как правило, можно легко избежать. А если можно легко избежать, значит это нужно сделать, чтобы удержать себя от излишнего соблазна "оверюза"... Например, для контроля количества экземпляров объекта вполне можно (и нужно) использовать различного рода фабрики.
Наибольшая же опасность, как было сказано, подстерегает при попытке построить на основе сиглтонов всю архитектуру приложения, такому подходу существует масса замечательных альтернатив. Например, IoC контейнеры — там проблема контроля создания сервисов решается естественным образом, так как они, по сути, являются "фабриками на стероидах" =). Другой альтернативой являются Service Locator-ы, из известных вариантов этого подхода — паттерн IServiceProvider.

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

IB>Другой альтернативой являются Service Locator-ы, из известных вариантов этого подхода — паттерн IServiceProvider.

А сервис у кого запрашивать?

Здравствуйте, IT, Вы писали:
IT>А сервис у кого запрашивать?
У другого сервиса.
Сервиспровайдера тебе засунут через IoC. Вся идея в том, что тебе не надо делать в каждом классе по восемнацать IoC-входов: для логгирования, для транзакций, для коммуникаций и т.п. Ты делаешь одну дырку, в которую тебе суют IServiceProvider и ты окучиваешь его по мере необходимости.

Лично меня всегда такие схемы напрягали, потому что совершенно не видно, кто кого использует, и откуда что берется. Прямо как в анекдоте:
— Деньги где берешь?
— В тумбочке.
— А в тумбочке они откуда?
— Жена кладет
Ну и так далее. Но, наверное, есть какой-то способ расследовать такие штуки.

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

S>Здравствуйте, IT, Вы писали:
IT>>А сервис у кого запрашивать?
S>У другого сервиса.
S>Сервиспровайдера тебе засунут через IoC. Вся идея в том, что тебе не надо делать в каждом классе по восемнацать IoC-входов: для логгирования, для транзакций, для коммуникаций и т.п. Ты делаешь одну дырку, в которую тебе суют IServiceProvider и ты окучиваешь его по мере необходимости.

S>Лично меня всегда такие схемы напрягали, потому что совершенно не видно, кто кого использует, и откуда что берется. Прямо как в анекдоте:
S>- Деньги где берешь?
S>- В тумбочке.
S>- А в тумбочке они откуда?
S>- Жена кладет
S>Ну и так далее. Но, наверное, есть какой-то способ расследовать такие штуки.

А если IoC контейнер не используется как подсунуть одно "окно" не используя сингелтон?

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

MS>А если IoC контейнер не используется как подсунуть одно "окно" не используя сингелтон?
Через GetService(...). Сервисы образуют иерархию, каждый дочерний сервис имеет ссылку на родителя, и если при вызове GetService искомый сервис на данном уровне не нашелся, вызов делегируется выше по иерархии, и так до тех пор пока не доберется до корневого сервис-локатора.
В этом смысле синглтон еще большая гадость, так как позволяет добраться до корневого сервиса в обход иерархии.

Почитай подробнее про IServiceProvider, например здесь: Lightweight Containers and Plugin Architectures: Dependency Injection and Dynamic Service Locators in .NET

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

IB>"главная проблема синглтона в том, что это первый паттерн описанный в GoF" (c) MaximVK. На него набрасываются и не замечают его недостатков, из коих:

Это не недостатки синглтона ни в коем случае, не надо воодить народ к заблуждение.

IB>1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров.

Это глупость, причём документально подтверждённая GoF. Действительно, в GoF синглтон описан как

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

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

template<T>
class singleton
{
    public:
        static const T * get_instance();
    private:
        static T * _instance;
}

либо

class Singleton<T> where T: new
{
    private static T _instance = default(T);
    public static T Instance { get; }
}
// или даже
class Singleton<T> where T: new, ISingleton
{
    private static T _instance = default(T);
    public static T Instance { get; }
}

либо как-то ещё, смотря от языка.

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

Singleton это stateless объект. Всякая другая его реализация ошибочна. Я тебя тут вообще не понял. Ты сперва сделал синглотон statefull объектом, а потом начал рассказывать какой синглотон плохой. Но это не синглтон плохой, это ты плохой, что сделал его statefull. Не надо путать тёплое с мягким.

IB>3. Зависимость обычного класса от синглтона не видна в публичном контракте класса. Так как обычно экземпляр синглтона не передается в параметрах метода, а получается напрямую, через GetInstance(), то для выявления зависимости класса от синглтона надо залезть в тело каждого метода — просто просмотреть публичный контракт объекта недостаточно.

Опять таки, ты сперва делаешь неверное предположение, а потом исходя из него строишь какие-то домыслы о недостатках синглтона. Кто сказал что зависимость обычного класса от синглтона должна быть видна? Вот у меня DAL зависит от системы журналирования, но из внешнего интерфейса DAL это не видно. И что? Я не вижу тут абсолютно никакой проблемы, тем более не вижу проблемы в синглтоне через который ведётся журналирования. Такого рода зависимости видны в настройках проекта и этого боле чем достаточно.

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

Во-первых, подкинуть Mock объект запросто можно (смотри второй пример на C#), во-вторых наличие состояний у синглтона это зло, причём зло в мозгах программиста, а не в синглтоне.

IB>Говоря же проще — синглтон повышает связность, и все вышеперечисленное, в том или ином виде, есть следствие повышения связности.

Да вообще зависимость одних модулей от других повышает связность

IB>Естественно, можно акккуратненько пройти по граблям и использовать синглетон, но (цитата из доки к пикоконтейнеру) "Overuse makes for bad solutions. At the enterprise level, it makes for very very bad solutions"...

Граблей никаких нет, если есть элементарное понимание области применения синглтона.

IB>Наибольшая же опасность, как было сказано, подстерегает при попытке построить на основе сиглтонов всю архитектуру приложения, такому подходу существует масса замечательных альтернатив. Например, IoC контейнеры — там проблема контроля создания сервисов решается естественным образом, так как они, по сути, являются "фабриками на стероидах" =). Другой альтернативой являются Service Locator-ы, из известных вариантов этого подхода — паттерн IServiceProvider.

Объясни мне доступно чем

GetService(typeof(MyService))

принципиальное лучше чем

Singleton<MyService>.Instance

если у нас всего один сервис.
Аргументы за сервисы, которые ты приводишь, актуальны, когда есть потребность в Chain of Responsibility, но это совсем другая задача.

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

A>Singleton это stateless объект. Всякая другая его реализация ошибочна. Я тебя тут вообще не понял. Ты сперва сделал синглотон statefull объектом, а потом начал рассказывать какой синглотон плохой. Но это не синглтон плохой, это ты плохой, что сделал его statefull. Не надо путать тёплое с мягким.
Можно вопрос? А какой смысл в stateless-синглтоне? Чем он лучше класса со статическими методами? Тем более, что в статических методах нам еще компилятор по рукам надает, если мы добавим нестатическое поле в класс.

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

IT>>А сервис у кого запрашивать?
S>У другого сервиса.
S>Сервиспровайдера тебе засунут через IoC. Вся идея в том, что тебе не надо делать в каждом классе по восемнацать IoC-входов: для логгирования, для транзакций, для коммуникаций и т.п. Ты делаешь одну дырку, в которую тебе суют IServiceProvider и ты окучиваешь его по мере необходимости.

Дырка может и одна, да только вынуть через неё всё что нужно не всегда получается. Иногда приходится через неё вытягивать что-то, у чего уже можно вытянуть то, что надо. А иногда таких приседаний надо сделать 2-3. Мэджик ещё тот получается. Даже не знаю что хуже, синглетон или вот такой сервис-провайдер.

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

A>Объясни мне доступно чем

GetService(typeof(MyService))

принципиальное лучше чем

Singleton<MyService>.Instance

если у нас всего один сервис.

Щас тебя порвут.

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

A>Singleton это stateless объект. Всякая другая его реализация ошибочна. Я тебя тут вообще не понял. Ты сперва сделал синглотон statefull объектом, а потом начал рассказывать какой синглотон плохой. Но это не синглтон плохой, это ты плохой, что сделал его statefull. Не надо путать тёплое с мягким.

Довольно странное утверждение...
Какой смысл вообще в stateless синглтоне? Чем он отличается от статик-методов?
Имхо смысл синглтона в возможности ленивой инициализации (i.e. statefull) и управления числом экземпляров (для stateless тоже не вижу смысла).
Плюс, объясни, если не сложно, как в

Singleton<MyService>.Instance

ты подсунешь мок? Или Instance — property, которая реализует фабрику?

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

IT>Дырка может и одна, да только вынуть через неё всё что нужно не всегда получается.
Ну это уж, извиняюсь, особенности реализации конкретной дырки..
Понятно, что кривой реализацией можно самую красивую идею испохабить, хотя конечно ISP не самый очевидный паттерн, со своими нюансами...

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

C>Можно вопрос? А какой смысл в stateless-синглтоне? Чем он лучше класса со статическими методами? Тем более, что в статических методах нам еще компилятор по рукам надает, если мы добавим нестатическое поле в класс.

Синглтон лучше класса со статическими методами двумя вещами: отложенной инициализацией и возможностью реализовать интерфейс.

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

C>>Можно вопрос? А какой смысл в stateless-синглтоне? Чем он лучше класса со статическими методами? Тем более, что в статических методах нам еще компилятор по рукам надает, если мы добавим нестатическое поле в класс.
A>Синглтон лучше класса со статическими методами двумя вещами: отложенной инициализацией и возможностью реализовать интерфейс.
Что можно инициализировать в stateless-синглтоне?

Интерфейс — это уже интереснее. Но я слабо представляю когда это нужно.

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

К>Довольно странное утверждение...
К>Какой смысл вообще в stateless синглтоне? Чем он отличается от статик-методов?

Уже писал: отложенная инициализация + реализация интерфейса.

К>Или Instance — property, которая реализует фабрику?

Как вариант. Сделать

Singleton<IMyService>.Instance;

и возвращать разные реализации IMyService в зависимости от того находимся ли мы в режиме тестирования или нет.
Учитывая специфику задачи (нам нужен compile-time полиморфизм) я бы предпочёл в 90% случаев ограничиться условной компиляцией.

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

C>Что можно инициализировать в stateless-синглтоне?
C>Интерфейс — это уже интереснее. Но я слабо представляю когда это нужно.

Зависит от синглтона. Возьмём конкретный, близкий почти всем, пример — журналирование.
Вызов Logger.Log(string message) очевидно не меняет состояния Logger, потому что у него нет никакого состояния. В терминах Си++ это

class Logger
{
    public:
        void Log(string message) const;
}

С другой стороны в процессе инициализации я могу захотеть открыть файл, сокет, соединение с БД и т.д.
Что касается интерфейса, в зависимости от настроек приложения, системы, аппаратной конфигурации могут возвращаться разные версии синглтона. То есть для

interface ILogger
{
    public:
        virtual void Log(string message) const = 0;
}

Могут быть возвращены LoggerRuRu, LoggerEnUs, LoggerOptimizedForPentium4, LoggerWithSelfTrace и т.п. Естественно, что для того кто использует синглтон это должно быть скрыто. Интерфейсы тут помогают.

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

[cut]
A>Могут быть возвращены LoggerRuRu, LoggerEnUs, LoggerOptimizedForPentium4, LoggerWithSelfTrace и т.п. Естественно, что для того кто использует синглтон это должно быть скрыто. Интерфейсы тут помогают.

Т.е. реализуем фабрику вместе с синглтоном и приписываем её свойства синглтону, не знаю что и сказать

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

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

К>>Довольно странное утверждение...
К>>Какой смысл вообще в stateless синглтоне? Чем он отличается от статик-методов?

A>Уже писал: отложенная инициализация + реализация интерфейса.

Инициализация чего? Объект-то у нас stateless.
Про интерфейсы — рядом

К>>Или Instance — property, которая реализует фабрику?

A>Как вариант. Сделать
A>

A>Singleton<IMyService>.Instance;
A>

Что сделать? Ты в ответ на приведённый мной код его продублировал и что ты хотел этим показать?

A>и возвращать разные реализации IMyService в зависимости от того находимся ли мы в режиме тестирования или нет.
A>Учитывая специфику задачи (нам нужен compile-time полиморфизм) я бы предпочёл в 90% случаев ограничиться условной компиляцией.

Понятно — подменяем понятия...

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

A>С другой стороны в процессе инициализации я могу захотеть открыть файл, сокет, соединение с БД и т.д.
Пардон, это уже не stateless. А самый настоящий stateful.

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

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

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

Люди ошибаются. С этим ничего не поделаешь.

IB>Понятно, что кривой реализацией можно самую красивую идею испохабить, хотя конечно ISP не самый очевидный паттерн, со своими нюансами...

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

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

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

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

A>Это не недостатки синглтона ни в коем случае,
Гм.. А кого?

A> не надо воодить народ к заблуждение.
Ну хорошо, давай разберемся кто, кого и куда вводит... =)

A>Это глупость, причём документально подтверждённая GoF.
Хорошее начало.. Рома, мне нравится твой энтузиазм, это оказывается GoF глупые, или ребята решили пошутить, ну или просто набросали код левой пяткой, а весь мир уже больше десяти лет думает, что синглтон выглядит именно так.. =)
Вообще, у тебя какая-то странная трактовка общепринятых терминов, вот и GoF в очередной раз досталось, конечно, они совсем другое имели ввиду. Я одного понять не могу, ты действительно так думаешь или просто намеренно искажаешь? С другой стороны — нет худа без добра, разжевав что-то тебе, можно быть уверенным, что объяснение дойдет до самого задумчивого жирафа в наших джунглях и уж точно не может быть истолковано двояко..

A> Однако, не стоит заниматься буквоедством, тем более там, где это нелепо выглядит.
Отличные слова, Ром, запиши их, а лучше запомни и постарайся применять их к себе по чаще..
Ладно, шутки в сторону.

A> Всякий нормальный программист отделяет задачу контроля количества копий и пишет нечто вроде
Угу, ты все очень правильно написал. И знаешь как это называется? Правильно "фабрика". Знаешь в чем разница между синглтоном и фабрикой?
Экземпляр синглтона нельзя создать в обход фабричного метода, что достигается за счет внесения этого метода в создаваемый класс, со всеми вытекающими последствиями (нарушение SRP). Если же код создания выносится в отдельную, независимую сущность (опять-таки со всеми вытекающими, как-то возможность создать копию в обход фабричного метода), которая занимается исключительно созданием нужных нам экземпляров, то мы имеем дело с другим паттерном, имя которому никак не синглтон.
Так что выбирай, но осторожно, но выбирай.

A>Singleton это stateless объект. Всякая другая его реализация ошибочна.
Смело.. Впрочем, про состояния синглтона тебе уже все рассказали.

A> Но это не синглтон плохой, это ты плохой, что сделал его statefull.
Ну, допустим, я плохой. А все остальные хорошие? Как будем контролировать, что никто, из тех кто реализует синглтон не сделает его statefull, просто потому что так показалось удобнее и не просчитав последствий?

A>Не надо путать тёплое с мягким.
Во-во. Речь-то именно о том, чем грозит использование (в том числе и не правильное) синглтона, а не описание как реализовать его правильно, если ты не заметил, так что не путай... =)

A>Опять таки, ты сперва делаешь неверное предположение,
Просто катастрофа какая-то, ты вообще мне отвечаешь или кого другого читал?... Здесь я вообще никаких предположений не делаю, я делаю одно простое утверждение.

A> Кто сказал что зависимость обычного класса от синглтона должна быть видна?
Как бы тебе так, по проще объяснить... Давай попробуем подняться на более высокий уровень абстракции, забыть про синглтоны и сформулировать одну аксиому: "Если одна сущность зависит от другой и эта зависимость не видна в публичном контракте — это плохо".
Аксиома — это потому, что я не собираюсь доказывать тебе истинность данного утверждения. Дальше можешь продолжить эту мысль в применении к синглтонам.

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

A>Граблей никаких нет, если есть элементарное понимание области применения синглтона.
Угу, или того, что называть синглтоном, и что такое грабли.

A>Объясни мне доступно чем

GetService(typeof(MyService))

принципиальное лучше чем

Singleton<MyService>.Instance

если у нас всего один сервис.
А кто говорит про один сервис? Ром, ты вообще внимательно читаешь? ISP предлагался для сценариев, когда необходимо выстроить всю архитектуру приложения на сервисах.

A>Аргументы за сервисы, которые ты приводишь, актуальны, когда есть потребность в Chain of Responsibility, но это совсем другая задача.
Во-первых CoR здесь не причем, а во-вторых, я предлагал это как решение ровно для тех задачь, где есть в этом потребность. Читай внимательно, прежде чем критиковать бросаться..

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

К>Т.е. реализуем фабрику вместе с синглтоном и приписываем её свойства синглтону, не знаю что и сказать

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

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

C>И получаются все те же проблемы. Например, если ты захочешь, чтобы половина программы у тебя использовала кодировку RU_UTF-8, а другая половина — EN_US, то у тебя будут все проблемы синглтонов.

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

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

IB>Хорошее начало.. Рома, мне нравится твой энтузиазм, это оказывается GoF глупые, или ребята решили пошутить, ну или просто набросали код левой пяткой, а весь мир уже больше десяти лет думает, что синглтон выглядит именно так.. =)

Не извращай, я кажется, достаточно ясно сказал что между кодом в книге и кодов в приложении есть разница. У Кнута, например, описано 6 вариантов QuickSort'а, ты используешь один, если вообще используешь. Надо головой работать, а не тупо с книжки переписывать и всё получиться.

A>> Всякий нормальный программист отделяет задачу контроля количества копий и пишет нечто вроде
IB>Угу, ты все очень правильно написал. И знаешь как это называется? Правильно "фабрика". Знаешь в чем разница между синглтоном и фабрикой?

Фабрика генерирует разные реализации интерфейса, мой код, вообще говоря, — нет. Так что опять промазал.

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

Э-э-э-э, ты опять перепутал особенности Java, и особенности синглтона. В Си++ чтобы синглтон нельзя было создать в обход фабричного метода ничего никуда заносить не надо. Нечего записывать в недостатки паттерна убогость/недоразвитость языка программиования, на котором он реализовывается.

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

Никак не будем. У тебя есть другие решения (не синглтон) которые запросто делаются statefull?

IB>Речь-то именно о том, чем грозит использование (в том числе и не правильное) синглтона, а не описание как реализовать его правильно, если ты не заметил, так что не путай... =)

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

IB>Как бы тебе так, по проще объяснить... Давай попробуем подняться на более высокий уровень абстракции, забыть про синглтоны и сформулировать одну аксиому: "Если одна сущность зависит от другой и эта зависимость не видна в публичном контракте — это плохо".
IB>Аксиома — это потому, что я не собираюсь доказывать тебе истинность данного утверждения. Дальше можешь продолжить эту мысль в применении к синглтонам.

Забавно. Вот, например, SQL сервер работает с файлами, но в публичном контракте ADO этого не видно. Обидно. Как же они так, а? А может твоя аксиома неправильная и детали реализации не должны торчать наружу?

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

A>>С другой стороны в процессе инициализации я могу захотеть открыть файл, сокет, соединение с БД и т.д.
C>Пардон, это уже не stateless. А самый настоящий stateful.

В том или ином виде state присутствует всегда, просто если он не меняется (дескриптор файла ведь не меняется после открытия), то классифицировать объект как stateful не правильно.

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

C>>И получаются все те же проблемы. Например, если ты захочешь, чтобы половина программы у тебя использовала кодировку RU_UTF-8, а другая половина — EN_US, то у тебя будут все проблемы синглтонов.
A>Если я такое захочу, то синглтон уже становится неприменим и никакой проблемы вобщем-то нет, потому что синглтона (или такой реализации синглтона) не будет.
Проблема будет, если ты захочешь это сделать в версии 1.1 продукта. Когда уже написаны мегабайты кода. Вот поэтому синглтон — по большей части и является антипаттерном.

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

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

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

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

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

A>Фабрика генерирует разные реализации интерфейса,
Она может генерировать разные реализации некоего интерфейса, а может одну вполне конкретную — это просто частный случай. Ты же сам призывал не заниматься буквоедством и не глядеть тупо в книгу, а думать.. Ну вот подумай..

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

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

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

A> Мне лично интересно как умный и понимающий человек может неожиданно для себя запутаться.
Больше всего косяков допускают как раз "умные и понимающие", которые точно знают как правильно использовать синглтон и не боятся его применять.
Правда, периодически забывают что такое состояние.. )

A>Забавно. Вот, например, SQL сервер работает с файлами, но в публичном контракте ADO этого не видно.
Зато это видно в публичном контракте БД, поскольку это она работает с файлами, а не ADO. А в публичном контракте ADO видно, с какой БД, сервером и базой идет работа.

A> А может твоя аксиома неправильная и детали реализации не должны торчать наружу?
Детали реализации тут не причем, просто смирись..

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

IB>Разница на столько сильная, что они опубликовали откровенно кривую реализацию, причем на нескольких языках?

Тю. Откуда в GoF несколько языков? Там всё на Яве.

A>>Фабрика генерирует разные реализации интерфейса,
IB>Она может генерировать разные реализации некоего интерфейса, а может одну вполне конкретную — это просто частный случай.

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

IB>Ты опять не внимательно читаешь, ключевое слово было "не связанный". Связь между классами друзьями в c++ настолько сильная, что вынос фабричного кода в отдельного "друга", по факту, мало чем отличается от реализации в том же классе, соблюсти SRP это не поможет.

Отличается, и боюсь, что сильно, но, увы, учить тебя Си++ выходит за рамки данной дискуссии.

A>>Никак не будем. У тебя есть другие решения (не синглтон) которые запросто делаются statefull?
IB>Следи за руками. беда в том, что синглтон глобален и имеет состояние.

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

A>> А может твоя аксиома неправильная и детали реализации не должны торчать наружу?
IB>Детали реализации тут не причем, просто смирись..

Так сказал учитель... ©
Сам мучайся со своими догмами

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

A>Тю. Откуда в GoF несколько языков? Там всё на Яве.

Ты, прости, вообще GoF-то видел? FUI — С++, Java, SmallTalk. Более того, там даже словами все расписано.
Но что нам слова? Это же книга, в книге нельзя написать правильно, вечно что-то мешает, в реальной-то жизни все по другому.. Но не беда, у нас есть Рома, он нам наконец-то все объяснит.. Вообще, учитывая причудливую терминологию, ты какой-то странный GoF читаешь... Или что-то еще меняет сознание?

A>Тем не менее, это всё же реализация интерфейса.
Отличная идея. То есть, как только фабрика порождает конкретный класс, который ничего не реализует — она тут же становится синглтоном? Так вот оказывается что GoF под синглтоном имели ввиду, а контроль экземпляров и единая точка доступа — это так, рюшечки.

A>Синглтон тоже может, но не объязан, фабрика объязана.
Фабрика никому ничего не обязана. Ее задача — породить экземпляр объекта, будет ли этот экземпляр реализацией какого либо интерфейса или нет, фабрики совершенно не касается.

A>Отличается, и боюсь, что сильно, но, увы, учить тебя Си++ выходит за рамки данной дискуссии.
То есть, переводя на русский, аргументов по делу нет но что-то сказать надо.. )

A>Нет состояния.
Рома, это мантра, а мантры, к сожалению, не работают на окружающую действительность. От того, что ты себя убедишь в отсутствии состояния, оно все равно никуда не денется. И это состояние будут пихать в синглтоны, сколько бы ты не кричал, что это не правильно.

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

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

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

IB>1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров.

Значит, любой клас с конструктором — антипаттерн.

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

А если у тебя экземпляр предоставляется IoC-контроллером, то типа, этих проблем нет?

IB>3. Зависимость обычного класса от синглтона не видна в публичном контракте класса. Так как обычно экземпляр синглтона не передается в параметрах метода, а получается напрямую, через GetInstance(), то для выявления зависимости класса от синглтона надо залезть в тело каждого метода — просто просмотреть публичный контракт объекта недостаточно.

А если у тебя экземпляр предоставляется IoC-контроллером, то типа, этих проблем нет?

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

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

А с IoC-контроллерами своя беда — возрастает сложность (и вероятность ошибок) в нсатройке и корректном соединении всех компонентов.

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

iT>Значит, любой клас с конструктором — антипаттерн.
А что, в любом классе конструктор занимается контролем количества экземпляров?

iT>А если у тебя экземпляр предоставляется IoC-контроллером, то типа, этих проблем нет?
Этих нет, без типа.

iT>А если у тебя экземпляр предоставляется IoC-контроллером, то типа, этих проблем нет?
И этих тоже нет.

iT>Вот это, по-моему, единственная реальная проблема.
Странная логика, если проблема, по твоим словам, проявляется не только в синглтоне, то это вроде как уже и не проблема?

iT>А с IoC-контроллерами своя беда — возрастает сложность (и вероятность ошибок) в нсатройке и корректном соединении всех компонентов.
Выбирай, но осторожно, но выбирай.

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

MS>Я понимаю, что тема возможно избита, но все же у кого какие мысли?
MS>Есть критерии использования этого паттерна, которые выверены на практике.

На практике, часто сталкиваюсь со следующей задачей:

— Физически на машине присутствует одно устройство
— Необходимо обеспечить доступ к нему из некоторого числа потоков

Самое простое решение использовать Singleton.
Из плюсов — очевидно простая реализация потокобезопасного обращения с устройством и
отсутсвие необходимости хранения потоком класса реализации устройства

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

IB>Ты, прости, вообще GoF-то видел? FUI — С++, Java, SmallTalk. Более того, там даже словами все расписано.

Бумажное издание за 2006 год у меня на столе, так что видел, даже внутрь заглядывал. Основной язык там Ява, Smalltalk не знаю и потому не скажу, код на Си++ является простым неоптимальным портированием и не использует всех возможностей языка. Например, нет описания синлтона Мейерса. Для меня достаточно очевидно, что код

template <typename T>
class singleton
{
    public:
        static const T & get_instance()
        {
            static T instance;
            
            return instance;
        }
};

class worker
{
    friend singleton<worker>;
    
    private:
        worker()
        {
        }
};

singleton<worker> s;
    
const worker & w = s.get_instance();

делает тоже самое, что в книжке и при этом на порядок лучше.

IB>Отличная идея. То есть, как только фабрика порождает конкретный класс, который ничего не реализует — она тут же становится синглтоном?

Нет, она перестаёт быть фабрикой.

IB>Фабрика никому ничего не обязана. Ее задача — породить экземпляр объекта, будет ли этот экземпляр реализацией какого либо интерфейса или нет, фабрики совершенно не касается.

Жжёшь. Иван, ты похоже попросту не знаешь паттерна Factory Method. Обсуждать что-либо с тобой, соответственно, абсолютно бесполезно.
Factory Method порождает реализации для интерфейсов, не важно сколько реализций, важно что все они реализуют некоторый интерфейс. Если тебе надо объяснять такие вещи, то я уже абсолютно не удивляюсь, что обломавшись со stateful синглтонами ты пошёл искать спасение на стороне.

A>>Отличается, и боюсь, что сильно, но, увы, учить тебя Си++ выходит за рамки данной дискуссии.
IB>То есть, переводя на русский, аргументов по делу нет но что-то сказать надо.. )

Иван, по делу, ты:
1. Отрицаешь возможность реализации stateless синглтонов.
2. Не понимаешь паттерна Factory Method и путаешь с ним Си++ код выше в этом сообщении.
3. Утверждаешь что все зависимости должны быть видны во внешнем интерфейсе.

Все три пункта страшное заблуждение.

A>>Нет состояния.
IB>Рома, это мантра, а мантры, к сожалению, не работают на окружающую действительность.

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

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

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

На самом деле я уже и сам писал библиотеку журналирования и с существующими, такие вещи делаются настройками. Объективно, когда у тебя есть разделяемый системный ресурс (тот же файл) синглтон не просто естественное, но и наиболее удобное решение.
Я работал с портом log4j на Си++. Авторы класс-логгер синглтоном не сделали. В результате пришлось его инициализировать, а потом таскать параметром по всем функциям. Вряд ли это было хорошее решение

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

Не, совсем ничего не использовать не выдет, надо использовать что-то вместо них. Вопрос в том что именно и насколько это оправдано.
Я согласен с IB, что stateful синглтон — зло, не согалсен что написать stateless — проблема.

Что-то вроде следующего:

class SomeResource {
    Mutex mu_;
    
    public:
    SomeResource();

// Подразумевается, что Adress имеет одну физическую точку доступа( /dev/device ),
// но несколько логических ( devInternal1, devInternal2 ...)
    void sendCommand( Adress , Command );
};

void SomeResource::sendCommand( Adress adress, Command command){
    MutexLocker( mu_ );
    ResourceKeeper res( adress );

    res.send( command );
}

typedef Singleton< SomeResource > Device;

Далее в библиотеке:

class Indicator{
public:
// name = "devInternal1"
    Indicator(const string& name);
    
    void indicate(Level l);
}

Внутри реализации Indicator:

void Indicator::indicate(...){
    Device::GetInstance.sendCommand(...)
}

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

IB>Странная логика, если проблема, по твоим словам, проявляется не только в синглтоне, то это вроде как уже и не проблема?

Проблема не специфичная для синглтона

IB>Выбирай, но осторожно, но выбирай.

Зачем осторожно? Шило на мыло меняешь, выходит, если опять осторожно надо.

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

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

[]

A>> Кто сказал что зависимость обычного класса от синглтона должна быть видна?
IB>Как бы тебе так, по проще объяснить... Давай попробуем подняться на более высокий уровень абстракции, забыть про синглтоны и сформулировать одну аксиому: "Если одна сущность зависит от другой и эта зависимость не видна в публичном контракте — это плохо".
IB>Аксиома — это потому, что я не собираюсь доказывать тебе истинность данного утверждения. Дальше можешь продолжить эту мысль в применении к синглтонам.

В топку твою аксиому. Никто никому ничего не обязан показывать в своём интерфейсе. Есть такое понятие как детали имплементации

[]

A>>Граблей никаких нет, если есть элементарное понимание области применения синглтона.
IB>Угу, или того, что называть синглтоном, и что такое грабли.

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

A>>Объясни мне доступно чем

GetService(typeof(MyService))

принципиальное лучше чем

Singleton<MyService>.Instance

если у нас всего один сервис.
IB>А кто говорит про один сервис? Ром, ты вообще внимательно читаешь? ISP предлагался для сценариев, когда необходимо выстроить всю архитектуру приложения на сервисах.

Дык, а откуда брать рутовый сервис? Ручками создавать? Типа rootService = new RootService( ...... ). Ха-ха. Так это еще больше связывает код, чувак.

A>>Аргументы за сервисы, которые ты приводишь, актуальны, когда есть потребность в Chain of Responsibility, но это совсем другая задача.
IB>Во-первых CoR здесь не причем, а во-вторых, я предлагал это как решение ровно для тех задачь, где есть в этом потребность. Читай внимательно, прежде чем критиковать бросаться..

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

КЛ>Дык, а откуда брать рутовый сервис? Ручками создавать? Типа rootService = new RootService( ...... ). Ха-ха. Так это еще больше связывает код, чувак.
Про IoC (он же "dependency injection") ты слышал?

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

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

MS>>Я понимаю, что тема возможно избита, но все же у кого какие мысли?
IB>Итого дискуссий по синглтону:

IB>"главная проблема синглтона в том, что это первый паттерн описанный в GoF" (c) MaximVK. На него набрасываются и не замечают его недостатков, из коих:

IB>1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров.

неправда. adontz уже показал почему.

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

Ты серьезно? Неужели у нас _вообще_ не бывает глобально одиноких сущностей, в приципе?
А почему мы не знаем его текущее состояние? Че за лажа?
Зависимость? ну так строй все на интерфейсах. Совсем уйти от зависимости тебе и IServiceProvider не поможет.

IB>3. Зависимость обычного класса от синглтона не видна в публичном контракте класса. Так как обычно экземпляр синглтона не передается в параметрах метода, а получается напрямую, через GetInstance(), то для выявления зависимости класса от синглтона надо залезть в тело каждого метода — просто просмотреть публичный контракт объекта недостаточно.

Извини чувак, но это

ISomeClass
{
    void Do( IServiceProvider )

    or

    void Do( Ilogger )
}

ничем не лучше

ISomeClass
{
    void Do()
}

по созданию зависимостей.

[]

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

A>В том или ином виде state присутствует всегда, просто если он не меняется (дескриптор файла ведь не меняется после открытия), то классифицировать объект как stateful не правильно.

А безграмостность растёт...

Stateful Objects: A stateful object is an object that maintains and changes internal state over time.

maintains — есть, changes — нет.

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

КЛ>Ты серьезно? Неужели у нас _вообще_ не бывает глобально одиноких сущностей, в приципе?
А зачем они нужны? Типичное приложение можно построить без единой глобальной переменной.

КЛ>А почему мы не знаем его текущее состояние? Че за лажа?
КЛ>Зависимость? ну так строй все на интерфейсах. Совсем уйти от зависимости тебе и IServiceProvider не поможет.
Поможет. Можешь посмотреть, например, на Spring — как там задают зависимости с помощью внешнего конфига.

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

A>>В том или ином виде state присутствует всегда, просто если он не меняется (дескриптор файла ведь не меняется после открытия), то классифицировать объект как stateful не правильно.
A>А безграмостность растёт...
A>

Stateful Objects: A stateful object is an object that maintains and changes internal state over time.

A>maintains — есть, changes — нет.
Фига. Определение — в помойку.

Например, String — это immutable-объект, так что он не меняет свое состояние. Будешь утверждать, что String — stateless?

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

C>Например, String — это immutable-объект, так что он не меняет свое состояние. Будешь утверждать, что String — stateless?

Если ты про System.String из .Net Framework, то да, буду.
У тебя есть другое определение? Поделись.

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

C>>Например, String — это immutable-объект, так что он не меняет свое состояние. Будешь утверждать, что String — stateless?
A>Если ты про System.String из .Net Framework, то да, буду.
Мда.

A>У тебя есть другое определение? Поделись.
Есть. Stateless = не имеющий состояния. Любой stateless-объект может быть заменен на любой другой объект (того же класса, естественно) без изменения поведения.

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

КЛ>>Дык, а откуда брать рутовый сервис? Ручками создавать? Типа rootService = new RootService( ...... ). Ха-ха. Так это еще больше связывает код, чувак.
C>Про IoC (он же "dependency injection") ты слышал?

А кто тебе будет впрыскивать?

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

КЛ>>>Дык, а откуда брать рутовый сервис? Ручками создавать? Типа rootService = new RootService( ...... ). Ха-ха. Так это еще больше связывает код, чувак.
C>>Про IoC (он же "dependency injection") ты слышал?
IT>А кто тебе будет впрыскивать?
Внешняя система конфигурации, например.

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

IT>А кто тебе будет впрыскивать?

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

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

A>>У тебя есть другое определение? Поделись.
C>Есть. Stateless = не имеющий состояния. Любой stateless-объект может быть заменен на любой другой объект (того же класса, естественно) без изменения поведения.

Нууу, это ты описал pure static объект, а не stateless. Stateless это когда результат вызова метода объекта не зависит от предыдущих вызовов.
На вот, почитай
http://whatis.techtarget.com/definition/0,,sid9_gci213051,00.html
http://www.webopedia.com/TERM/S/stateless.html

Having no information about what occurred previously.

— в самую точку.

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

IT>>А кто тебе будет впрыскивать?
C>Внешняя система конфигурации, например.

Что значит внешняя? Внешняя по отношению к чему? И почему внутренняя уже не канает?

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

A>>>У тебя есть другое определение? Поделись.
C>>Есть. Stateless = не имеющий состояния. Любой stateless-объект может быть заменен на любой другой объект (того же класса, естественно) без изменения поведения.
A>Нууу, это ты описал pure static объект, а не stateless.
Поэтому я и утверждаю, что "stateless"-синглтон изоморфен объекту со статическими методами.

A>Stateless это когда результат вызова метода объекта не зависит от предыдущих вызовов.
Это "идемпотентный" объект — http://en.wikipedia.org/wiki/Idempotent

A>На вот, почитай
A>http://whatis.techtarget.com/definition/0,,sid9_gci213051,00.html
A>http://www.webopedia.com/TERM/S/stateless.html
A>

Having no information about what occurred previously.

— в самую точку.
Именно. Твои синглтоны ЗНАЮТ что, с ними "have occurred previously" — они знают про свои параметры инициализации, в частности.

Соответственно, у твоих "stateless"-синглтонов ровно те же проблемы, что и у "обычных".

PS: блин, это ты удалил прошлое сообщение? Я как раз на него отвечал.

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

IT>>>А кто тебе будет впрыскивать?
C>>Внешняя система конфигурации, например.
IT>Что значит внешняя? Внешняя по отношению к чему?
Внешняя по отношению к коду. Смотри Spring, например: http://www.springframework.net/

IT>И почему внутренняя уже не канает?
Можно и внутреннюю — то есть тупо передавать нужные параметры в конструктор.

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

C>Внешняя по отношению к коду. Смотри Spring, например: http://www.springframework.net/

А в Spring конфигуратор как реализован? Как синглетон? Или он конфигурируется другой внешней системой конфигурации?

IT>>И почему внутренняя уже не канает?
C>Можно и внутреннюю — то есть тупо передавать нужные параметры в конструктор.

Кто их должен передавать?

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

C>>Внешняя по отношению к коду. Смотри Spring, например: http://www.springframework.net/
IT>А в Spring конфигуратор как реализован? Как синглетон? Или он конфигурируется другой внешней системой конфигурации?
Как угодно. Например, ты можешь его положить в theadlocal-переменную, впрыскивать его в объекты или передавать явно.

IT>>>И почему внутренняя уже не канает?
C>>Можно и внутреннюю — то есть тупо передавать нужные параметры в конструктор.
IT>Кто их должен передавать?
Объект, создающий данный объект.

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

IT>>А в Spring конфигуратор как реализован? Как синглетон? Или он конфигурируется другой внешней системой конфигурации?
C>Как угодно. Например, ты можешь его положить в theadlocal-переменную, впрыскивать его в объекты или передавать явно.

Т.е. на каждую поток у нас будет по одному конфигуратору? В чём смысл?

IT>>>>И почему внутренняя уже не канает?
C>>>Можно и внутреннюю — то есть тупо передавать нужные параметры в конструктор.
IT>>Кто их должен передавать?
C>Объект, создающий данный объект.

А кто будет создавать объект, создающий данный объект?

iT>>Значит, любой клас с конструктором — антипаттерн.
IB>А что, в любом классе конструктор занимается контролем количества экземпляров?

Конечно! Он позволяет создать еще один экземпляр, что увеличивает количество на 1.

iT>>А если у тебя экземпляр предоставляется IoC-контроллером, то типа, этих проблем нет?
IB>Этих нет, без типа.
И как же это так получается, интересно... Вот ты настраиваешь IoC так, чтобы тебе возвращался один и тот же экземпляр (singleton scope).
И что — это не будет похоже на глобальную переменную в плане разделения состояния?

IoC — это только способ вынесения зависимости в другое место. Какие это зависимости — по-прежнему зависит от тебя.
И плюсы/минусы этих зависимостей остаются теми же.

iT>>А если у тебя экземпляр предоставляется IoC-контроллером, то типа, этих проблем нет?
IB>И этих тоже нет.

Теперь здесь. Я надеюсь, ты не включаешь в понятие "публичного контракта класса" конфиг IoC, в котором написано, какие компоненты нужно к нему прицепить?
И по-прежнему, зависимость просто выносится в конфиг, а в контракте ее как не было, так и не нет.
То есть тот, кто будет разрабатывать клиента для этого класса, точно также не узнает, что в результате клас будет использовать такой-то синглтон/сервис для своей реализации.

iT>>Вот это, по-моему, единственная реальная проблема.
IB>Странная логика, если проблема, по твоим словам, проявляется не только в синглтоне, то это вроде как уже и не проблема?

Если проблема проявляется не только в синглтоне, то не нужно приписывать ее синглтону как таковому, выявляя таким образом, его "антипаттерность".

iT>>А с IoC-контроллерами своя беда — возрастает сложность (и вероятность ошибок) в нсатройке и корректном соединении всех компонентов.
IB>Выбирай, но осторожно, но выбирай.
Именно. Вешай ярлыки, но осторожно

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

C>Именно. Твои синглтоны ЗНАЮТ что, с ними "have occurred previously" — они знают про свои параметры инициализации, в частности.

Не-не, инициализация, очевидно, не в счёт. Иначе stateless объектами будет только константный мусор в памяти. Имеется ввиду только то что occured после инициализации и до текущего момента.

C>Соответственно, у твоих "stateless"-синглтонов ровно те же проблемы, что и у "обычных".

Какие например? Методы можно дёргать откуда угодно и в любом порядке, какие тут могут быть проблемы?

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

iT>IoC — это только способ вынесения зависимости в другое место. Какие это зависимости — по-прежнему зависит от тебя.
iT>И плюсы/минусы этих зависимостей остаются теми же.

Плюсы/минусы остаются. Разница в том, что количество проблемных мест с этими плюсами/минусами резко сокращается, а в большинстве случаев стремится к нулю.

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

C>>Именно. Твои синглтоны ЗНАЮТ что, с ними "have occurred previously" — они знают про свои параметры инициализации, в частности.
A>Не-не, инициализация, очевидно, не в счёт. Иначе stateless объектами будет только константный мусор в памяти. Имеется ввиду только то что occured после инициализации и до текущего момента.
Именно. Stateless-объектов почти не существует (они бесполезны). У любого полезного объекта есть состояние, которое может за время жизни меняться или не меняться.

Бывают stateless-сервисы (т.е. логические сущности), которые при этом состоят из вполне себе stateful-объектов.

C>>Соответственно, у твоих "stateless"-синглтонов ровно те же проблемы, что и у "обычных".
A>Какие например? Методы можно дёргать откуда угодно и в любом порядке, какие тут могут быть проблемы?
Глобальность.

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

IT>>>А в Spring конфигуратор как реализован? Как синглетон? Или он конфигурируется другой внешней системой конфигурации?
C>>Как угодно. Например, ты можешь его положить в theadlocal-переменную, впрыскивать его в объекты или передавать явно.
IT>Т.е. на каждую поток у нас будет по одному конфигуратору? В чём смысл?
Бывает нужно иногда (я не говорю, что это очень хороший паттерн). Например, если надо передать конфигуратор через слой, который мы не контролируем, и в который мы не можем нормально его воткнуть.

IT>>>Кто их должен передавать?
C>>Объект, создающий данный объект.
IT>А кто будет создавать объект, создающий данный объект?
Объект, который будет создавать объект, который будет создавать объект. И так рекурсивно до функции main().

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

C>Бывают stateless-сервисы (т.е. логические сущности), которые при этом состоят из вполне себе stateful-объектов.

по-моему, ты перемудрил.

C>Глобальность.

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

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

C>>Бывают stateless-сервисы (т.е. логические сущности), которые при этом состоят из вполне себе stateful-объектов.
A>по-моему, ты перемудрил.
Не знаю. Просто stateless-объекты для меня больше похоже на нонсен.

C>>Глобальность.
A>Вообще-то синглтон затевался из-за глобальной точки доступа, так что называть глобальность недостатком достаточно странно.
Вот эта глобальность — и есть плохо. Я вообще предпочитаю всегда передавать все необходимые для вычисления данные в локальном контексте.

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

A>Бумажное издание за 2006 год у меня на столе, так что видел, даже внутрь заглядывал.
Значит все-таки сознание изменяет что-то другое..

A> Для меня достаточно очевидно, что код делает тоже самое, что в книжке и при этом на порядок лучше.
Я тебе уже объяснил, почему ты заблуждаешься.. )

A>Нет, она перестаёт быть фабрикой.
С какой стати?

A>Жжёшь. Иван, ты похоже попросту не знаешь паттерна Factory Method.
Ну давай посмотрим, кто чего не знает "Factory Method — Define an interface for creating an object." Все, точка. Про то что object должен реализовывать какие-то интерфейсы не сказано ни слова. Рома, ты определенно читаешь либо не тот GoF, либо странным способом.

A>Обсуждать что-либо с тобой, соответственно, абсолютно бесполезно.


A>Factory Method порождает реализации для интерфейсов, не важно сколько реализций, важно что все они реализуют некоторый интерфейс.
Вот это как раз, абсолютно не важно, для того чтобы называться "фабричным методом", совершенно не обязательно порождать объекты реализующие определенный интерфейс. Берем твой любимый C++, там нет нарошной сущности для декларации публичного контракта, а значит любая фабрика все равно завязана на конкретный класс.

Ну да фиг с ним. Это все буквоедство и словоблудие, важно другое. Бедулька в том, что ты не знаешь общепринятой терминологии и в место того, чтобы просто уточнить и согласовать набор терминов, становишся в неимоверно пафосную позу и начинаешь спорить не разобравшись.
В данном случае твое заблуждение состоит в том, что ты не в курсе довольно известного факта: the term factory method is often used to refer to any method whose main purpose is creation of objects. И именно в этом смысле я употреблял термин "фабрика" (самостоятельная сущность, задача которой порождать объекты, конкретный паттерн factory method здесь вообщем-то не причем), и понятно это было вообщем-то всем, кроме, как выяснилось, тебя.

A>1. Отрицаешь возможность реализации stateless синглтонов.
Хм.. Смотря что иметь ввиду под stateless. Через твою терминологию я боюсь не продраться.

A>2. Не понимаешь паттерна Factory Method
Здесь, я надеюсь, ты уже осознал свое заблуждение. Можешь не извеняться..

A> и путаешь с ним Си++ код выше в этом сообщении.
Это ты путаешь, про связность сишных френдов я тебе уже рассказывал..

A>Все три пункта страшное заблуждение.
Поправочка. Все три пункта — твое страшное заблуждение..

A> Люди годами инкапсулировали, а пришёл добрый дядя Ваня и раскапсулировал всё нафиг, потому что нефиг
Новый термин выучил? Перечитай еще раз внимательно, что это такое, а главное, для чего его используется и медитируй над тем, зачем придумали паттерн IoC... Осознаешь — приходи..

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

iT>Конечно! Он позволяет создать еще один экземпляр, что увеличивает количество на 1.
Ну тебе-то, надеюсь, не надо разжевывать, что означает слово "контроль"?

iT>И что — это не будет похоже на глобальную переменную в плане разделения состояния?
Нет, не будет.

iT>IoC — это только способ вынесения зависимости в другое место.
Угу. В то место, где я могу явным образом контролировать эти зависимости.

iT>И плюсы/минусы этих зависимостей остаются теми же.
Минусов заметно меньше.

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

iT>Если проблема проявляется не только в синглтоне, то не нужно приписывать ее синглтону как таковому,
Вот странный ты. А кому же еще ее приписывать? Синглтон обладает очевидным недостатком => синглтон плохой. Даже если кто-то еще обладает этим недостатком синглтон от этого лучше не станет.

iT>Именно. Вешай ярлыки, но осторожно
Можешь привести цитату, где я повесил на синглтон ярлык?

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

КЛ>неправда. adontz уже показал почему.
Гм.. Повторить сможешь? Увы, но Роме это не удалось...

КЛ>А почему мы не знаем его текущее состояние? Че за лажа?
Господи, ну что за манеры... Выйди из класса, и зайди как учили.
"- Иван Дмитриевич, объясните пожалуйста, почему нам не очевидно состояние глобальной переменной". Давай, я жду... Дневник оставь.

КЛ>Извини чувак, но это
Сейчас вообще за родителями пойдешь, может хоть они тебя научат вопросы вежливо задавать..

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

A>>Жжёшь. Иван, ты похоже попросту не знаешь паттерна Factory Method.
IB>Ну давай посмотрим, кто чего не знает "Factory Method — Define an interface for creating an object." Все, точка. Про то что object должен реализовывать какие-то интерфейсы не сказано ни слова. Рома, ты определенно читаешь либо не тот GoF, либо странным способом.

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

Паттерн Factory Method

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

Фабричный метод — паттерн, порождающий классы.

Назначение

Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать. Фабричный метод позволяет классу делегировать инстанцирование подклассам.

Известен также под именем

Virtual Constructor (виртуальный конструктор).

Для тех кто в танке, я ключевые моменты выделил.

A>>Factory Method порождает реализации для интерфейсов, не важно сколько реализций, важно что все они реализуют некоторый интерфейс.
IB>Вот это как раз, абсолютно не важно, для того чтобы называться "фабричным методом", совершенно не обязательно порождать объекты реализующие определенный интерфейс.

Учи матчасть, порождать объекты реализующие определенный интерфейс очень даже объязательно. Цитаты выше.

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

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

IB>В данном случае твое заблуждение состоит в том, что ты не в курсе довольно известного факта: the term factory method is often used to refer to any method whose main purpose is creation of objects. И именно в этом смысле я употреблял термин "фабрика" (самостоятельная сущность, задача которой порождать объекты, конкретный паттерн factory method здесь вообщем-то не причем), и понятно это было вообщем-то всем, кроме, как выяснилось, тебя.

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

IB>Хм.. Смотря что иметь ввиду под stateless. Через твою терминологию я боюсь не продраться.

Терминология не моя, я давал ссылки. Общаясь в форуме, постарайся не только писать, но и читать то, что пишут другие.

A>>2. Не понимаешь паттерна Factory Method
IB>Здесь, я надеюсь, ты уже осознал свое заблуждение. Можешь не извеняться..

Можешь и дальше юродствовать, если по существу сказать нечего.

A>> и путаешь с ним Си++ код выше в этом сообщении.
IB>Это ты путаешь, про связность сишных френдов я тебе уже рассказывал...

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

A>> Люди годами инкапсулировали, а пришёл добрый дядя Ваня и раскапсулировал всё нафиг, потому что нефиг
IB>Новый термин выучил? Перечитай еще раз внимательно, что это такое, а главное, для чего его используется и медитируй над тем, зачем придумали паттерн IoC... Осознаешь — приходи..

IoC это не паттерн, хотя вряд ли ты это понимаешь...

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

A>ага, пошло цитирование неизвестно чего, неизвестно откуда,
Известно чего..

A>лишь бы не признать своей неправоты.
Лишь бы до тебя хоть что-то донести. Тебе уже пора бы приплачивать мне за науку..

A>Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать. Фабричный метод позволяет классу делегировать инстанцирование подклассам.
....
A>Учи матчасть, порождать объекты реализующие определенный интерфейс очень даже объязательно. Цитаты выше.
Я прям даже теряюсь... Ты сам-то хоть понял, что процитировал и что сказал? В твоей цитате речь про фабричный метод, то есть, про порождающую сущность, а пишешь ты про интерфейс порождаемой сущности... Это даже не теплое с мягким, это просто винегрет какой-то.

A>Для тех кто в танке, я ключевые моменты выделил.
Да. Те кто в танке сказали ровно тоже что и я, но, очевидно, не разобравшись, по запарке.
Еще раз, по буквам, это если в танке люк заварен. Есть порождающая сущность (фабрика), есть порождаемая (объект). Смысл конкретно паттерна "фабричный метод" предоставить интерфейс фабрики для создания объекта. Об этом же и говорит второе название "виртуальный конструктор", понимаешь, конструктор виртуальный, а не объект.
Это если формализмом заниматься. Реально, как я уже говорил, в данном определении "интерфейс" понятие довольно условное, и в некоторых языках "из-за их убогости/недоразвитости"(с) недостижимое.

A>Я по крайне мере умею читать
Рома, прости, но вот данное утверждение после ряда дискуссий с тобой, вызывает очень серьезные сомнения в своей истинности. У меня суровое подозрение, что ты себе льстишь..

A>Забавно, когда дело касается синглтона ты занимаешься буквоедством,
Остаюсь верен себе, просто называю вещи своими именами..

A> а когда фабричного метода довольно свободно трактуешь.
Фабричного метода я вообще не касался, это ты про него речь завел. Да и трактовка не моя, а википедии, что касается общепринятого мнения — это достаточно надежный источник. Так что все претензии туда, если общепринятое определение, почему-то не совпадает с твоим.

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

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

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

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

A>>Определяет интерфейс для создания объекта, но оставляет подклассам решение о том, какой класс инстанцировать. Фабричный метод позволяет классу делегировать инстанцирование подклассам.
IB>....
A>>Учи матчасть, порождать объекты реализующие определенный интерфейс очень даже объязательно. Цитаты выше.
IB>Я прям даже теряюсь... Ты сам-то хоть понял, что процитировал и что сказал? В твоей цитате речь про фабричный метод, то есть, про порождающую сущность, а пишешь ты про интерфейс порождаемой сущности... Это даже не теплое с мягким, это просто винегрет какой-то.

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

Применимость

Используйте паттерн фабричный метод, когда:

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

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

см цитату выше.

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

template <typename T>
class singleton
{
    public:
        static const T & get_instance()
        {
            static T instance;
            
            return instance;
        }
};

class worker
{
    friend singleton<worker>;
    
    private:
        worker()
        {
        }
};

singleton<worker> s;
    
const worker & w = s.get_instance();

Где тут доступ к приватным полям? Тут полей вообще нет. Доступ из singleton<worker> к приватному конструктору worker::worker() это фича, а не недостаток.

IB>Ок, буквоед ты наш, назови это "архитектурный принцип", на вопрос-то можешь ответить?

Если по простому, IoC придумали чтобы избежать циклических зависимостей, для разрешения которых приходится, обычно, порождать лишние модули (попутно, там, обычно, особенности реализации наружу торчат). IoC бывает двух видов, dependecy injection и колбеки.

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

node * get_first();
node * get_next();
data * get_data(node *);

породив помимо модулей linked_list и application, модуль linked_list_declarations описывающий тип node от которого зависят linked_list и application, а могу как

enumerate_nodes(bool (* enum_proc)(data *));

и это очевидно лучше, потому что

1. Клиент больше не зависит от типа node.
   
2. Нет вспомогательных модулей.
   
3. Клиент больше не доступны несущественные детали реализации.

Dependency injection ИМХО зло, я уже говорил, что кортежи внедрённых зависимостей в параметрах каждого метода (запоминать нельзя, мало ли...) ни к чему хорошему не приводит. Настроили журналирование в файл на самом высоком уровне (функция main если угодно) и давай этот объект тащить до низу. Особенно весело, если раньше журналирования не было и надо весь проект переписать, чтобы оно вдруг было. Так как весь проект переписывать лень, появляются хаки (всякие thread local переменные, описанные Cyberax). В этом смысле singleton выглядет куда привлекательнее, так как позволяет добавлять в нижние уровни функциональность контроллируемую в верхних уровнях, не протаскивая её через все промежуточные уровни.
Callback'и на мой взгляд более приемлемое решение (особенно делегатами), но практическая реализация нередко затруднена. Кроме того этот самый указатель/делегат надо опять таки передать через все уровни и реальная разница в сложности реализации и поддержки между Dependency injection и Callback стирается.
В целом вырисовывается следующая картина:

// singleton
void level3()
{
    singleton<logger>::log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}
int main()
{
    singleton<logger>::initialize(bla-bla-bla);
    level1();
}
// dependency injection
void level3(logger log)
{
    log.log("level 3!");
}
void level2(logger log)
{
    level3(log);
}
void level1(logger log)
{
    level2(log);
}
int main()
{
    logger log;

    log.initialize(bla-bla-bla);

    level1(log);
}

Нередко level1 и level2 написаны вообще не мной, это может быть, например, код какой-то библиотеки которая вызывает level3 как callback. В такой ситуации синглтон оказывается очень кстати.
Сервисы это круто, особенно их .Net реализация с автоматическим приведением типов, но эти сервисы надо где-то регистрировать и откуда-то брать. А когда начинаешь думать где регистрировать, откуда брать... Хорошо если есть главный объект-контейнер, а если нет такого объекта?

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

A>В целом вырисовывается следующая картина:

А так?

void level3()
{
    log.log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}

logger log;

int main(logger pLog)
{
    log = pLog;
    level1();
}

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

A>Вообще-то синглтон затевался из-за глобальной точки доступа, так что называть глобальность недостатком достаточно странно.

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

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

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

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


P,S, Сингелтоны не использую и не защищаю .

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

IT>А так?

void level3()
{
    log.log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}

logger log;

int main(logger pLog)
{
    log = pLog;
    level1();
}

Так не скомпилируется, у функции main параметрами могут быть только (int argc, char ** argv)

logger log;

void level3()
{
    log.log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}

int main( pLog)
{
    logger log;

    log.initialize(bla-bla-bla);

    level1(log);
}

Тоже не будет работать. level1, level2, level3 будут в разных единицах компиляции и иметь общую глобальную переменную им не светит.

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

A>>Вообще-то синглтон затевался из-за глобальной точки доступа, так что называть глобальность недостатком достаточно странно.
M>А я думал чтобы обеспечить единственность экземпляра.

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

Паттерн Singleton

Назначение

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

Применимость

Используйте паттерн одиночка, когда:

• должен быть ровно один экземпляр некоторого класса, легко доступный
  всем клиентам;
  
• единственный экземпляр должен расширяться путем порождения подклас-
  сов, и клиентам нужно иметь возможность работать с расширенным экземп-
  ляром без модификации своего кода.

учи матчасть.

Похоже что ты даже то что сам написал не читаеш. Прочти еще раз назначение патерна.

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

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

M>И ты серьезно считаешь что доступность можно обеспечить только через глобальность?

Нет не думаю, это твои бредовые слова не мои. Доступно можно ещё, например, через broadcast сообщения о поиске обеспечить (если конечно есть некоторая общедоступная система обмена сигналами).

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

M>>И ты серьезно считаешь что доступность можно обеспечить только через глобальность?

A>Нет не думаю, это твои бредовые слова не мои. Доступно можно ещё, например, через broadcast сообщения о поиске обеспечить (если конечно есть некоторая общедоступная система обмена сигналами).

Тогда прочти предыдущий свой пост , где ты пишешь про голобальность.

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

M>Тогда прочти предыдущий свой пост , где ты пишешь про голобальность.

И что там не так?

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

C>Здравствуйте, Константин Л., Вы писали:

КЛ>>Ты серьезно? Неужели у нас _вообще_ не бывает глобально одиноких сущностей, в приципе?
C>А зачем они нужны? Типичное приложение можно построить без единой глобальной переменной.

Что значит нужны? Они есть независимо от того, хотим мы этого или нет.

КЛ>>А почему мы не знаем его текущее состояние? Че за лажа?
КЛ>>Зависимость? ну так строй все на интерфейсах. Совсем уйти от зависимости тебе и IServiceProvider не поможет.
C>Поможет. Можешь посмотреть, например, на Spring — как там задают зависимости с помощью внешнего конфига.

На Spring смотреть не охота, но верю на слово.

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

IB>Здравствуйте, Константин Л., Вы писали:

КЛ>>неправда. adontz уже показал почему.
IB>Гм.. Повторить сможешь? Увы, но Роме это не удалось...

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

КЛ>>А почему мы не знаем его текущее состояние? Че за лажа?
IB>Господи, ну что за манеры... Выйди из класса, и зайди как учили.
IB>"- Иван Дмитриевич, объясните пожалуйста, почему нам не очевидно состояние глобальной переменной". Давай, я жду... Дневник оставь.



Извини, конечно, грубовато, но вот то что ты написал про невозможность узнать текущее состояние — лажа и есть

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

Чувак и лажа появились не просто так, а в ответ на твою учительско-дневниковскую манеру высказывать своё мнение. Вот она и тут проявилась

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

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

A>>В целом вырисовывается следующая картина:

IT>А так?

IT>

IT>void level3()
IT>{
IT>    log.log("level 3!");
IT>}
IT>void level2()
IT>{
IT>    level3();
IT>}
IT>void level1()
IT>{
IT>    level2();
IT>}

IT>logger log;

IT>int main(logger pLog)
IT>{
IT>    log = pLog;
IT>    level1();
IT>}
IT>

А это, пардон, откуда? Да и разницы особой не вижу

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

КЛ>>>Ты серьезно? Неужели у нас _вообще_ не бывает глобально одиноких сущностей, в приципе?
C>>А зачем они нужны? Типичное приложение можно построить без единой глобальной переменной.
КЛ>Что значит нужны? Они есть независимо от того, хотим мы этого или нет.
Что значит "есть"? Можешь привести хороший пример?

У меня, например, в GUI-приложении ровно 0 глобальных переменных в моем коде (что творится в библиотеках — я точно не знаю).

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

C>У меня, например, в GUI-приложении ровно 0 глобальных переменных в моем коде (что творится в библиотеках — я точно не знаю).

Извини, это прыжок в сторону. Если ты накидал на форму компоненты и обошлся без глобальных сущностей, это вовсе не означает, что их нет.
Любой аппаратный или разделяемый системный ресурс представляет собой глобальную сущность. У тебя всего одно сетевое соединение, а не по штучке на пакет, у тебя всего один принт-спулер, у тебя всего одно соединение с БД. Далеко не для всех из них надо городить синглтон. Я уже указывал, что синглтоны полезны когда мы хотим протащить сущность из верхнего слоя в нижний (или наоборот) минуя (не затрагивая) промежуточные слои. В остальных случаях IoC бывает достаточно. Но IoC через 4-5 слоёв абстрагирования это редкостный геморрой.

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

КЛ>Чувак и лажа появились не просто так, а в ответ на твою учительско-дневниковскую манеру высказывать своё мнение. Вот она и тут проявилась

Мания Величко страшная женщина...

P.S. На самом деле, чем больше Бодягин выставляет свою "мудрость" на показ, тем больше я в неё не верю. Имел счастье общаться с действительно хорошими педагогами, прямо скажем — другой стиль. Иван не плохой специалист, но как и всякий долго работавший, оброс субъективными предрассудками, которые, увы, любит выставлять истиной в последней инстанции.

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

C>Здравствуйте, Константин Л., Вы писали:

КЛ>>Дык, а откуда брать рутовый сервис? Ручками создавать? Типа rootService = new RootService( ...... ). Ха-ха. Так это еще больше связывает код, чувак.
C>Про IoC (он же "dependency injection") ты слышал?

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

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

C>>У меня, например, в GUI-приложении ровно 0 глобальных переменных в моем коде (что творится в библиотеках — я точно не знаю).
A>Извини, это прыжок в сторону. Если ты накидал на форму компоненты и обошлся без глобальных сущностей, это вовсе не означает, что их нет.
У меня кроме простого GUI еще много чего интересного есть.

A>Любой аппаратный или разделяемый системный ресурс представляет собой глобальную сущность.
С чего ты взял? Вот сетевая карта, к примеру — делаем ее синглтоном (hint: драйверы для всем известного Realtek 8149). А потом грызем бамбук, когда пользователь устанавливает ДВЕ сетевые карты.

Точно так же и почти со всем остальным оборудованием: звуковухами, приводами CD-ROM, мониторами, видеокартами и т.п.

A>У тебя всего одно сетевое соединение, а не по штучке на пакет, у тебя всего один принт-спулер
C чего ты взял?

A>у тебя всего одно соединение с БД.
С чего ты взял?

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

A>Далеко не для всех из них надо городить синглтон. Я уже указывал, что синглтоны полезны когда мы хотим протащить сущность из верхнего слоя в нижний (или наоборот) минуя (не затрагивая) промежуточные слои. В остальных случаях IoC бывает достаточно. Но IoC через 4-5 слоёв абстрагирования это редкостный геморрой.
Если IoC делать заранее — то потом добавление еще одного параметра делается легко и безболезненно. А в существующее приложение, действительно, приходится иногда вставлять синглтоновые хаки.

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

iT>>>Значит, любой клас с конструктором — антипаттерн.
IB>>А что, в любом классе конструктор занимается контролем количества экземпляров?

iT>Конечно! Он позволяет создать еще один экземпляр, что увеличивает количество на 1.

iT>>>А если у тебя экземпляр предоставляется IoC-контроллером, то типа, этих проблем нет?
IB>>Этих нет, без типа.
iT>И как же это так получается, интересно... Вот ты настраиваешь IoC так, чтобы тебе возвращался один и тот же экзе+мпляр (singleton scope).
iT>И что — это не будет похоже на глобальную переменную в плане разделения состояния?

+1

iT>IoC — это только способ вынесения зависимости в другое место. Какие это зависимости — по-прежнему зависит от тебя.
iT>И плюсы/минусы этих зависимостей остаются теми же.

+10

iT>>>А если у тебя экземпляр предоставляется IoC-контроллером, то типа, этих проблем нет?
IB>>И этих тоже нет.

iT>Теперь здесь. Я надеюсь, ты не включаешь в понятие "публичного контракта класса" конфиг IoC, в котором написано, какие компоненты нужно к нему прицепить?
iT>И по-прежнему, зависимость просто выносится в конфиг, а в контракте ее как не было, так и не нет.
iT>То есть тот, кто будет разрабатывать клиента для этого класса, точно также не узнает, что в результате клас будет использовать такой-то синглтон/сервис для своей реализации.

+100

iT>>>Вот это, по-моему, единственная реальная проблема.
IB>>Странная логика, если проблема, по твоим словам, проявляется не только в синглтоне, то это вроде как уже и не проблема?

+1

iT>Если проблема проявляется не только в синглтоне, то не нужно приписывать ее синглтону как таковому, выявляя таким образом, его "антипаттерность".

+1

iT>>>А с IoC-контроллерами своя беда — возрастает сложность (и вероятность ошибок) в нсатройке и корректном соединении всех компонентов.
IB>>Выбирай, но осторожно, но выбирай.
iT>Именно. Вешай ярлыки, но осторожно

+1

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

A>Тоже не будет работать. level1, level2, level3 будут в разных единицах компиляции и иметь общую глобальную переменную им не светит.
extern никто не отменял.

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

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

A>Callback'и на мой взгляд более приемлемое решение (особенно делегатами), но практическая реализация нередко затруднена. Кроме того этот самый указатель/делегат надо опять таки передать через все уровни и реальная разница в сложности реализации и поддержки между Dependency injection и Callback стирается.
Если использовать Dependency injection правильно, а не как ты то получается совсем другая картина:

void level3(ServiceProvider const* sp)
{
    sp->get<ILogger>()->log("level 3!");
}
void level2(ServiceProvider const* sp)
{
    level3(sp);
}
void level1(ServiceProvider const* sp)
{
    level2(sp);
}
int main()
{
    logger log;
    log.initialize(bla-bla-bla);

    ServiceProvider sp;
    sp.add<ILogger>(&log);

    level1(&sp);
}

А теперь добавим в лог вывод информации о втором уровне

void level3(ServiceProvider const* sp)
{
    sp->get<ILogger>()->log("level 3!");
}
void level2(ServiceProvider const* baseSp, bla-bla-bla)
{
    loggerWithSomeInfo log;
    log.initialize(baseSp->get<ILogger>(), bla-bla-bla);

    ServiceProvider sp(baseSp);
    sp.add<ILogger>(&log);

    level3(&sp);
}
void level1(ServiceProvider const* sp)
{
...
    level2(sp, bla-bla-bla);
...
}
int main()
{
    logger log;
    log.initialize(bla-bla-bla);

        ServiceProvider sp;
        sp.add<ILogger>(&log);

    level1(&sp);
}

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

Жду решение на синглетоне...
Только учти что level1 навызывал level2 в куче потоков с разными bla-bla-bla...

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

A>>Любой аппаратный или разделяемый системный ресурс представляет собой глобальную сущность.
C>С чего ты взял? Вот сетевая карта, к примеру — делаем ее синглтоном (hint: драйверы для всем известного Realtek 8149). А потом грызем бамбук, когда пользователь устанавливает ДВЕ сетевые карты.

Э, нет-нет. По синглтону на каждую физическую карту Realtek'у горячий привет.

A>>У тебя всего одно сетевое соединение, а не по штучке на пакет, у тебя всего один принт-спулер
C>C чего ты взял?

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

A>>у тебя всего одно соединение с БД.
C>С чего ты взял?

Ты подключаешься к БД заново для каждого запроса?

C>Большая часть перечисленого тобой в один прекрасный момент может вдруг перестать быть синглтоном.

Не перестанет, просто синглтон станет чуть сложнее обычного и в метод GetInstance придётся веести уточняющий параметр. В GoF это упоминается в комментариях.
Хорошим примером такого синглтона является класс CultureInfo. Метод CultureInfo.GetCultureInfo возвращает по-разному инициализированные экземпляры CultureInfo (в отличие от фабричного метода, который бы возвращал наследников CultureInfo). Уникальность поддерживается уже не на уровне типа, а на уровне типа+локали. Последовательные вызовы CultureInfo.GetCultureInfo(1049) вернут один и тот же объект и даже вызовы CultureInfo.GetCultureInfo(1049) и CultureInfo.GetCultureInfo("ru-RU") возвращают один и тот же объект. Это синглтон, просто уникальность экземпляра определяется уже не только типом. В твоём примере с реалтеками вполне могло быть NetworkAdapter.GetNetworkAdapter("15:35:28:15:14:95") и NetworkAdapter.GetNetworkAdapter("40:63:40:83:00:96") и это были бы синглтоны на уровне typeof(NetworkAdapter)+MAC.

C>Если IoC делать заранее — то потом добавление еще одного параметра делается легко и безболезненно. А в существующее приложение, действительно, приходится иногда вставлять синглтоновые хаки.

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

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

WH>extern никто не отменял.

Из DLL ок?

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

WH>Жду решение на синглетоне...
WH>Только учти что level1 навызывал level2 в куче потоков с разными bla-bla-bla...

Во-первых, ты подменил задачу, так что никакого решения на синглтоне не будет. Задача подмены сервисов изначально не стояла.
Во-вторых, представь что level2 и level3 менять нельзя (библиотечный код, причём не твой). Очень интересно как тебе помогут сервисы...

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

[]

да и мы иногда страдаем, чего греха таить

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

A>Так не скомпилируется, у функции main параметрами могут быть только (int argc, char ** argv)

Ну да, а так?

void level3()
{
    log.log("level 3!");
}
void level2()
{
    level3();
}
void level1()
{
    level2();
}

logger log;

int main1(logger pLog)
{
    log = pLog;
    level1();
}

int main()
{
    logger log;

    log.initialize(bla-bla-bla);
        
    main1(log);
}

A>Тоже не будет работать. level1, level2, level3 будут в разных единицах компиляции и иметь общую глобальную переменную им не светит.

Ну так ты тогда и приведи пример с разными единицами.

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

КЛ>А это, пардон, откуда?

Попытайся мыслить абстрактно.

КЛ>Да и разницы особой не вижу

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

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

A>Во-первых, ты подменил задачу, так что никакого решения на синглтоне не будет. Задача подмены сервисов изначально не стояла.
Она подменилась после того как наколбасили 10 метров кода... Или ты хочешь сказать что у тебя никогда требования не меняются?
В случае с Dependency injection проблем не возникает, а вот как такое провернуть на синглетонах...

A>Во-вторых, представь что level2 и level3 менять нельзя (библиотечный код, причём не твой). Очень интересно как тебе помогут сервисы...
Если эта библиотека не вызвает мой код то пофигу ибо библиотека по любому ничего не знает о моих структурах данных.
Если она вызывает мой код то все приличные библиотеки позволяют передать в Callback контекст вызова, а теми которые не позволяют это пользоваться в любом случае себе дороже.

А теперь всетки попробуй предоставить решение на синглетоне... да у нас уже есть 10 метров кода... использующие синглетон.

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

WH>>extern никто не отменял.
A>Из DLL ок?
Гм:
dll.h

#ifdef DLL_EXPORTS
#define DLL_API __declspec(dllexport)
#else
#define DLL_API __declspec(dllimport)
#endif

DLL_API void iddqdPrint();
DLL_API extern int iddqd;

dll.cpp

#include <iostream>
#include "dll.h"

DLL_API int iddqd = 0;
DLL_API void iddqdPrint()
{
    std::cout << iddqd << "\n";
}

test.cpp

#include "dll.h"
int main()
{
    for (int i = 0; i < 1000000; ++i)
    {
        iddqd = i * i;
        iddqdPrint();
    }
    return 0;
}

Ы?

Если ты про переносимый способ по его нет ибо С++ ничего про dll не знает.

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

C>>С чего ты взял? Вот сетевая карта, к примеру — делаем ее синглтоном (hint: драйверы для всем известного Realtek 8149). А потом грызем бамбук, когда пользователь устанавливает ДВЕ сетевые карты.
A>Э, нет-нет. По синглтону на каждую физическую карту Realtek'у горячий привет.
Как ты себе это представляешь?

class CardOneSinglton
{
};
CardOneSinglton cardOneInstance;

class CardTwoSinglton
{
};
CardTwoSinglton cardTwoInstance;
...

Так что ли?

A>>>У тебя всего одно сетевое соединение, а не по штучке на пакет, у тебя всего один принт-спулер
C>>C чего ты взял?
A>С чего я взял что ты не создаёшь новое подключение на каждый сетевой пакет? Я считал тебя умным, других оснований нет.
HTTP — он connectionless. То есть, иногда по одному соединению с keep-alive'ом могут несколько запросов пройти, но в общем случае — да, по соединению на запрос.

A>>>у тебя всего одно соединение с БД.
C>>С чего ты взял?
A>Ты подключаешься к БД заново для каждого запроса?
У меня из приложения вообще нет соединений с БД В качестве источника данных используется библиотека, которая общается с load-ballanced statless-сервисами на серверах.

C>>Большая часть перечисленого тобой в один прекрасный момент может вдруг перестать быть синглтоном.
A>Не перестанет, просто синглтон станет чуть сложнее обычного и в метод GetInstance придётся веести уточняющий параметр. В GoF это упоминается в комментариях.
Ага. А откуда ты значение этого "уточняющего параметра" будешь брать?

A>Это синглтон, просто уникальность экземпляра определяется уже не только типом. В твоём примере с реалтеками вполне могло быть NetworkAdapter.GetNetworkAdapter("15:35:28:15:14:95") и NetworkAdapter.GetNetworkAdapter("40:63:40:83:00:96") и это были бы синглтоны на уровне typeof(NetworkAdapter)+MAC.
А нафиг такое нужно? Это уже клиника.

Мы передаем MAC-адрес вместо того, чтобы передавать явную ссылку на NetworkAdapter.

C>>Если IoC делать заранее — то потом добавление еще одного параметра делается легко и безболезненно. А в существующее приложение, действительно, приходится иногда вставлять синглтоновые хаки.
A>Никогда в проекте ты не сможешь задействовать сторонние библиотеки полностью удовлетворяющие все твои фантазии.
У меня вот получается. Тем более, что никаких экзотических требований я не выдвигаю — нужно просто уметь передавать контекст. Я даже не могу вспомнить нормальную библиотеку, где это явно нельзя было бы делать. Разве что на ум приходит несколько кривых мест в WinAPI.

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

IT>Здравствуйте, Константин Л., Вы писали:

КЛ>>А это, пардон, откуда?

IT>Попытайся мыслить абстрактно.

попытался, но как ты сам сказал, "а впрыскивать кто будет?"

КЛ>>Да и разницы особой не вижу

IT>Здрасьте. Рома больше всего протестует по причине наличия у всей цепочки вызываемых методов дополнительного параметра. Скажу тебе по секрету. Такие параметры элементарно убираются и никаких проблем не вызывают.

Спасибо, что открыл тайну по секрету

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

Ну да ладно, полезность dep. inj. никто не оспаривает. Никто особо и не оспаривает наличие проблем у синглтона. Но вот устраивать охоту на ведьм и делать из IoC пришествие Христа тоже не рулез.

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

WH>Она подменилась после того как наколбасили 10 метров кода... Или ты хочешь сказать что у тебя никогда требования не меняются?
WH>В случае с Dependency injection проблем не возникает, а вот как такое провернуть на синглетонах...

Если я правильно понял твою задачу, то достаточно в качестве синглтона возвращать нечто реализующее chain of responsibility. Будет помесь двух паттернов. Добавятся методы внедрения и удаления звеньев, но существующий код переписывать не придётся.

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

Да тут понимаешь, в теории-то всё хорошо. А на практике бывает, что формально контекст вызова указать можно, но практически это какой-нибудь LPVOID. И сделать синглтон проще, чем трахаться с временем жизни unmanaged обёрток. А я, надо заметить, имею большой сексуальный опыт в этой сфере

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

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

КЛ>Убираются, запихиваясь во всевозможные контексты и т.п.

Только не в контексты, а в конструкторы или инициализаторы объектов.

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

A>Если я правильно понял твою задачу, то достаточно в качестве синглтона возвращать нечто реализующее chain of responsibility. Будет помесь двух паттернов. Добавятся методы внедрения и удаления звеньев, но существующий код переписывать не придётся.
Псевдокод можно? А то словами у тебя както не очень получилось объяснить.

A>Да тут понимаешь, в теории-то всё хорошо. А на практике бывает, что формально контекст вызова указать можно, но практически это какой-нибудь LPVOID.
Больше и не нужно.

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

A>Кроме того, был опущен вопрос времени жизни. В случае с сервисами я объязан их все создать заранее, просто чтобы зарегистрировать у провайдера, в случае с синглтонами ненужной инициализации нет. Конечно, можно всё обернуть в Lazy Initialization, но это уже больше похоже на костыли...
Я вот не помню ни одного случая когда отложенная инициализация имела смысл.
У меня постоянно получается что момент создания/разрушения сервисов строго определен.
Что я делаю не так?

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

[]

A>Да тут понимаешь, в теории-то всё хорошо. А на практике бывает, что формально контекст вызова указать можно, но практически это какой-нибудь LPVOID. И сделать синглтон проще, чем трахаться с временем жизни unmanaged обёрток. А я, надо заметить, имею большой сексуальный опыт в этой сфере

ну это уже проблема с++, а не dep. inj.

[]

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

IT>Здравствуйте, Константин Л., Вы писали:

КЛ>>Убираются, запихиваясь во всевозможные контексты и т.п.

IT>Только не в контексты, а в конструкторы или инициализаторы объектов.

А это можно было и не говорить.

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

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

IT>>Только не в контексты, а в конструкторы или инициализаторы объектов.
КЛ>А это можно было и не говорить.
КЛ>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
То есть, у тебя все объекты имеют пустые конструкторы? Ведь почти любой параметр в конструкторе — деталь реализации.

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

C>Здравствуйте, Константин Л., Вы писали:

IT>>>Только не в контексты, а в конструкторы или инициализаторы объектов.
КЛ>>А это можно было и не говорить.
КЛ>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
C>То есть, у тебя все объекты имеют пустые конструкторы? Ведь почти любой параметр в конструкторе — деталь реализации.

ну что за манера все доводить до абсурда?

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

IT>>Только не в контексты, а в конструкторы или инициализаторы объектов.

КЛ>А это можно было и не говорить.

Это нужно было сказать сразу. Иначе Рома опять истолкует всё по-своему.

КЛ>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.

А в чём проблема?

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

[]

КЛ>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.

IT>А в чём проблема?

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

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

C>Здравствуйте, Константин Л., Вы писали:

КЛ>>Ты серьезно? Неужели у нас _вообще_ не бывает глобально одиноких сущностей, в приципе?
C>А зачем они нужны? Типичное приложение можно построить без единой глобальной переменной.

КЛ>>А почему мы не знаем его текущее состояние? Че за лажа?
КЛ>>Зависимость? ну так строй все на интерфейсах. Совсем уйти от зависимости тебе и IServiceProvider не поможет.
C>Поможет. Можешь посмотреть, например, на Spring — как там задают зависимости с помощью внешнего конфига.

дык, библиотеки и прикладной код это две разные вещи.

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

C>>Поможет. Можешь посмотреть, например, на Spring — как там задают зависимости с помощью внешнего конфига.
КЛ>дык, библиотеки и прикладной код это две разные вещи.
И что? От библиотеки все что требуется — уметь передавать контекст. Бывают исключения, но уж очень редко.

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

A>Боже... ты неисправим... Винигрета никакого нет, просто я с дуру не так расставил ударения,
Ну, то есть, это я виноват, что ты даже не читаешь, что цитируешь..

A> Вот вобщем самая правильная цитата, тут ты уже не отвертишься.
Да куда уж мне, только умоляю, пафос убери..

A> класс спроектирован так, чтобы объекты, которые он создает, специфицировались подклассами;
Ооох, Ромушка... =) Ну когда же ты хоть сам себя-то читать научишься? Здесь опять речь о порождающей иерархии.
Более того, паттерн не обязательно должен удовлетворять всем пунктам из этого раздела. Это раздел о том, когда паттерн надо применять, а не описанеи паттерна.

A>см цитату выше.
С цитатами у тебя как-то не очень получается.. Своя голова есть?

A>Где тут доступ к приватным полям?
Нда, и после этого меня упрекают в буквоедстве...

A>Если по простому, IoC придумали чтобы избежать циклических зависимостей, для разрешения которых приходится, обычно, порождать лишние модули


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

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

КЛ>Ну как бы за создание экземпляра и его уникальность отвечает совсем другой класс

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

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

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

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

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

Можно.

БЫЛО

// типы
template <typename T>
class singleton
{
    public:
        static T & get_instance()
        {
            static T instance;
            
            return instance;
        }
};

class logger
{
    friend singleton<logger>;

    private:
        logger();
    public:
        void log(const char * message) const;
}
// использование
singleton<logger>.get_instance().log("some text");

СТАЛО

// типы
template <typename T>
class singleton
{
    public:
        static T & get_instance()
        {
            static T instance;
            
            return instance;
        }
};

class logging_part
{
    public:
        virtual void log(char * message, bool * is_canceled, bool * is_handled) = 0;
}

class text_logging_part : public logging_part
{
    public:
        virtual void log(char * message, bool * is_canceled, bool * is_handled);
}

class db_logging_part : public logging_part
{
    public:
        virtual void log(char * message, bool * is_canceled, bool * is_handled);
}

class logger
{
    public:
        void log(const char * message) const;    
        void add_part(logging_part * log, /* какие-то параметры указывающие приоритет вызова и т.п. */);
        void remove_part(logging_part * log);
}
// использование
text_logging_part tl;
db_logging_part dl;

singleton<logger>.get_instance().add_part(tl);

singleton<logger>.get_instance().add_part(dl);

// Вот тут ничего не поменялось. Если нужна ещё и бинарная совместимость, то делаем интерфейсы.
singleton<logger>.get_instance().log("some text");

A>>И сделать синглтон проще, чем трахаться с временем жизни unmanaged обёрток. А я, надо заметить, имею большой сексуальный опыт в этой сфере
WH>Ни разу со временем жизни проблем не возникало.

Проблема очевидная. Пишешь managed обёртку в виде какого-нибудь

class ManagedWrapper
{
    public event RakeEventHandler Rake
    {
        add
        {
            NativeMethods.AddCallbackTarget(value, GetContextForObject(value).ToIntPtr());
        }

        remove
        {
            NativeMethods.RemoveCallbackTarget(value, GetContextForObject(value).ToIntPtr());
        }
    }
}

и потом в коде

ManagedWrapper mw;

mw.Rake += MyHandler;

И получаешь грабли, потому что делегат указывавший на метод MyHandler был собран сборщиком мусора как неимеющий managed ссылок. Прямо скажем — неприятно. Приходится переписывать в виде

class ManagedWrapper
{
    public event RakeEventHandler Rake
    {
        add
        {
            SomeGlobalDelegateTable.Add(value);
            NativeMethods.AddCallbackTarget(value, GetContextForObject(value).ToIntPtr());
        }

        remove
        {
            NativeMethods.RemoveCallbackTarget(value, GetContextForObject(value).ToIntPtr());
            SomeGlobalDelegateTable.Remove(value);
        }
    }
}

потому что заставлять клиента явно создавать делегат и хранить на него ссылку не катит.
Таких сюрпризов у меня в своё время было не мало.

WH>Я вот не помню ни одного случая когда отложенная инициализация имела смысл.

Случай простой — инициализация тяжёлая операция и не всегда нужная. Мне, например, не нравятся приложения стартующие 2-3 минуты потому что программист не стал заморачиваться и решил инициализировать всё сразу.

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

КЛ>>>А это можно было и не говорить.
КЛ>>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
C>>То есть, у тебя все объекты имеют пустые конструкторы? Ведь почти любой параметр в конструкторе — деталь реализации.
КЛ>ну что за манера все доводить до абсурда?
Чтобы показать абсурдность твоей идеи.

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

КЛ>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
IT>А в чём проблема?

В том что если у тебя есть уровень1 в котором настраивается сущность, уровень2 которому на сущность начхать и уровень3 который использует сущность, то в результате изменения сущности надо переписывать уровень2.

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

IB>Да куда уж мне, только умоляю, пафос убери..

Ой, ну кто бы говорил. Ты себе аватарчик с нимбом уже заказал?

A>> класс спроектирован так, чтобы объекты, которые он создает, специфицировались подклассами;
IB>Ооох, Ромушка... =) Ну когда же ты хоть сам себя-то читать научишься? Здесь опять речь о порождающей иерархии.
IB>Более того, паттерн не обязательно должен удовлетворять всем пунктам из этого раздела. Это раздел о том, когда паттерн надо применять, а не описанеи паттерна.

Ещё раз, для особо одарённых.

класс спроектирован так, чтобы объекты, которые он создает, специфицировались подклассами;

речь о порождаемой иерархии.

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

IB>Хм.. У людей с адекватной самооценкой мой стиль изложения почему-то не вызывает негативной реакции.

Адекватная — это когда человек думает, что он глупее тебя? Я, в таком случае, чрезвычайно неадекватен.