Почему Singleton антипаттерн
От: IB Австрия http://rsdn.ru
Дата: 09.08.07 13:54
Оценка: 311 (24) +3
#Имя: FAQ.design.singleton_antipattern
Здравствуйте, 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.

Добавлено в FAQ. ДХ
... << RSDN@Home 1.2.0 alpha rev. 673>>
Мы уже победили, просто это еще не так заметно...
Re: Почему Singleton антипаттерн
От: Ужасть бухгалтера  
Дата: 13.08.07 12:47
Оценка: 46 (4) +4 :)
IB>"главная проблема синглтона в том, что это первый паттерн описанный в GoF" (c) MaximVK.

Подумалось...
"Вторая главная проблема синглтона в том, что это первый описанный антипаттерн".

Раньше же как было? На встреченную глобальную переменную: "Вы чё, чуваки, офигели? Всем срочно юзать паттерны! Есть же синглтон, в конце концов!". Говорящий при этом выглядит до фига крутым и умным: как же, умные книжки читает, использует паттерны проектирования, последние модные технологии, все дела...

То сейчас на встреченный синглтон: "Вы чё, чуваки, офигели? Вы шо, не знаете, шо синглтон — АНТИПАТТЕРН, ёптыть?!" Говорящий выглядит еще более крутым и умным, ибо читает, оказывается, еще более умные и модные книжки. При этом заодно повышает свою самооценку, т.к. получает возможность возвыситься над ретроградами, ничтожными юзерами синглтонов.

ИМХО, всему найдется свое место. И IoC полезен, и у синглтона есть область применения. И даже глобальную переменную иногда можно куда-нить приткнуть

ИМХО, лучше просто трезво оценивать возможную область применения синглтона, его плюсы/минусы и возможные альтернативы. А то из-за ожесточенного флейма в этой ветке возникает впечатление, что некоторые зачем-то пытаются свести использование синглтона вообще к нулю.
Re[3]: Singleton действительно антипаттерн в enterprize прил
От: Cyberax Марс  
Дата: 10.08.07 14:07
Оценка: +6
Здравствуйте, adontz, Вы писали:

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

Можно вопрос? А какой смысл в stateless-синглтоне? Чем он лучше класса со статическими методами? Тем более, что в статических методах нам еще компилятор по рукам надает, если мы добавим нестатическое поле в класс.
Sapienti sat!
Re[6]: Singleton действительно антипаттерн в enterprize прил
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.08.07 06:20
Оценка: :))) :))
Здравствуйте, IB, Вы писали:

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


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

A>>Фабрика генерирует разные реализации интерфейса,

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

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

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


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

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

IB>Следи за руками. беда в том, что синглтон глобален и имеет состояние.

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

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

IB>Детали реализации тут не причем, просто смирись..

Так сказал учитель... ©
Сам мучайся со своими догмами
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[6]: Почему Singleton антипаттерн
От: IT Россия linq2db.com
Дата: 12.08.07 22:23
Оценка: +4 :)
Здравствуйте, adontz, Вы писали:

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


Рома, ты — неадекватен.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[2]: Почему Singleton антипаттерн
От: IT Россия linq2db.com
Дата: 13.08.07 17:13
Оценка: +5
Здравствуйте, Ужасть бухгалтера, Вы писали:

УБ>ИМХО, всему найдется свое место. И IoC полезен, и у синглтона есть область применения. И даже глобальную переменную иногда можно куда-нить приткнуть


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

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

УБ>ИМХО, лучше просто трезво оценивать возможную область применения синглтона, его плюсы/минусы и возможные альтернативы. А то из-за ожесточенного флейма в этой ветке возникает впечатление, что некоторые зачем-то пытаются свести использование синглтона вообще к нулю.


Это очень легко объясняется. Разумные люди стараются не наступать на одни и теже грабли дважды и, поимев проблемы с синглетоном один раз, предпочитают больше с ним не связываться даже если его применение локально ограничено и проблем при модификации кода не вызывает. А учитывая, что серьёзных архитектурных преимуществ синглетон не даёт, то гораздо проще и разумнее предать его анафеме и не связываться с ним даже в тех случаях, когда с ним проблем не возникает.
Если нам не помогут, то мы тоже никого не пощадим.
Re[15]: Singleton действительно антипаттерн в enterprize при
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.08.07 17:13
Оценка: -2 :))
Здравствуйте, Cyberax, Вы писали:

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


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

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


Какие например? Методы можно дёргать откуда угодно и в любом порядке, какие тут могут быть проблемы?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[2]: Почему Singleton антипаттерн
От: IB Австрия http://rsdn.ru
Дата: 11.08.07 20:24
Оценка: +1 :)))
Здравствуйте, Константин Л., Вы писали:

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

Гм.. Повторить сможешь? Увы, но Роме это не удалось...

КЛ>А почему мы не знаем его текущее состояние? Че за лажа?

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

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

Сейчас вообще за родителями пойдешь, может хоть они тебя научат вопросы вежливо задавать..
Мы уже победили, просто это еще не так заметно...
Re[4]: Почему Singleton антипаттерн
От: Константин Л. Франция  
Дата: 12.08.07 14:21
Оценка: -1 :)))
Здравствуйте, 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

Re[2]: Singleton действительно антипаттерн в enterprize прил
От: adontz Грузия http://adontz.wordpress.com/
Дата: 10.08.07 13:58
Оценка: 7 (1) +1 :)
Здравствуйте, 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, но это совсем другая задача.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[7]: Singleton действительно антипаттерн в enterprize прил
От: Cyberax Марс  
Дата: 10.08.07 17:37
Оценка: 1 (1) +2
Здравствуйте, adontz, Вы писали:

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

Пардон, это уже не stateless. А самый настоящий stateful.

И получаются все те же проблемы. Например, если ты захочешь, чтобы половина программы у тебя использовала кодировку RU_UTF-8, а другая половина — EN_US, то у тебя будут все проблемы синглтонов.
Sapienti sat!
Re[3]: Singleton действительно антипаттерн в enterprize прил
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.08.07 02:27
Оценка: +2 :)
Здравствуйте, IT, Вы писали:
IT>А сервис у кого запрашивать?
У другого сервиса.
Сервиспровайдера тебе засунут через IoC. Вся идея в том, что тебе не надо делать в каждом классе по восемнацать IoC-входов: для логгирования, для транзакций, для коммуникаций и т.п. Ты делаешь одну дырку, в которую тебе суют IServiceProvider и ты окучиваешь его по мере необходимости.

Лично меня всегда такие схемы напрягали, потому что совершенно не видно, кто кого использует, и откуда что берется. Прямо как в анекдоте:
— Деньги где берешь?
— В тумбочке.
— А в тумбочке они откуда?
— Жена кладет
Ну и так далее. Но, наверное, есть какой-то способ расследовать такие штуки.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Singleton действительно антипаттерн в enterprize при
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.08.07 15:05
Оценка: :)))
Здравствуйте, Cyberax, Вы писали:

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


Если ты про System.String из .Net Framework, то да, буду.
У тебя есть другое определение? Поделись.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Singleton действительно антипаттерн в enterprize прил
От: IB Австрия http://rsdn.ru
Дата: 10.08.07 20:54
Оценка: 3 (1) :)
Здравствуйте, 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 здесь не причем, а во-вторых, я предлагал это как решение ровно для тех задачь, где есть в этом потребность. Читай внимательно, прежде чем критиковать бросаться..
Мы уже победили, просто это еще не так заметно...
Re[3]: Singleton действительно антипаттерн в enterprize прил
От: IT Россия linq2db.com
Дата: 10.08.07 14:10
Оценка: :))
Здравствуйте, adontz, Вы писали:

A>Объясни мне доступно чем
GetService(typeof(MyService))
принципиальное лучше чем
Singleton<MyService>.Instance
если у нас всего один сервис.


Щас тебя порвут.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[8]: Singleton действительно антипаттерн в enterprize прил
От: adontz Грузия http://adontz.wordpress.com/
Дата: 10.08.07 21:45
Оценка: :))
Здравствуйте, Cyberax, Вы писали:

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


Если я такое захочу, то синглтон уже становится неприменим и никакой проблемы вобщем-то нет, потому что синглтона (или такой реализации синглтона) не будет.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[6]: Singleton действительно антипаттерн в enterprize прил
От: IT Россия linq2db.com
Дата: 11.08.07 15:13
Оценка: +1 :)
Здравствуйте, Cyberax, Вы писали:

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

C>Про IoC (он же "dependency injection") ты слышал?

А кто тебе будет впрыскивать?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[3]: Почему Singleton антипаттерн
От: Константин Л. Франция  
Дата: 12.08.07 13:29
Оценка: :))
Здравствуйте, IB, Вы писали:

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


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

IB>Гм.. Повторить сможешь? Увы, но Роме это не удалось...

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

КЛ>>А почему мы не знаем его текущее состояние? Че за лажа?

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



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

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

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

Чувак и лажа появились не просто так, а в ответ на твою учительско-дневниковскую манеру высказывать своё мнение. Вот она и тут проявилась
Re[7]: Почему Singleton антипаттерн
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.08.07 08:18
Оценка: -1 :)
Здравствуйте, IB, Вы писали:

A>>Адекватная — это когда человек думает, что он глупее тебя?

IB>Адекватная — это когда человек не мыслит категориями "умнее/глупее" при оценке технического текста..

То что ты пишешь можно назвать техническим текстом с большой натяжкой. Большей частью это были наезды, игра в великого гуру, намёки на мою несообразительность (если не сказать тупость) и неблагодарность. Вот к этой, доминирующей, части текста твоих сообщений я и подхожу с оценкой умнее/глупее. А хоть какое-то рациональное зерно было только в самом первом ответе, потом только флуд и юродство.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re: Singleton действительно антипаттерн в enterprize приложе
От: Курилка Россия http://kirya.narod.ru/
Дата: 09.08.07 13:33
Оценка: :)
Здравствуйте, mr.sashich, Вы писали:

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

Почему обязательно enterprise? Он по любому антипаттерн, т.к. заведомо повышает связность приложения.
Re[2]: Singleton действительно антипаттерн в enterprize прил
От: IT Россия linq2db.com
Дата: 09.08.07 23:17
Оценка: :)
Здравствуйте, IB, Вы писали:

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


А сервис у кого запрашивать?
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Singleton действительно антипаттерн в enterprize прил
От: IT Россия linq2db.com
Дата: 10.08.07 14:10
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

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

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

Дырка может и одна, да только вынуть через неё всё что нужно не всегда получается. Иногда приходится через неё вытягивать что-то, у чего уже можно вытянуть то, что надо. А иногда таких приседаний надо сделать 2-3. Мэджик ещё тот получается. Даже не знаю что хуже, синглетон или вот такой сервис-провайдер.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Singleton действительно антипаттерн в enterprize прил
От: adontz Грузия http://adontz.wordpress.com/
Дата: 10.08.07 17:05
Оценка: -1
Здравствуйте, Курилка, Вы писали:

К>Довольно странное утверждение...

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

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

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


Как вариант. Сделать
Singleton<IMyService>.Instance;

и возвращать разные реализации IMyService в зависимости от того находимся ли мы в режиме тестирования или нет.
Учитывая специфику задачи (нам нужен compile-time полиморфизм) я бы предпочёл в 90% случаев ограничиться условной компиляцией.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[8]: Singleton действительно антипаттерн в enterprize прил
От: adontz Грузия http://adontz.wordpress.com/
Дата: 10.08.07 22:04
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

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

C>Пардон, это уже не stateless. А самый настоящий stateful.

В том или ином виде state присутствует всегда, просто если он не меняется (дескриптор файла ведь не меняется после открытия), то классифицировать объект как stateful не правильно.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[9]: Singleton действительно антипаттерн в enterprize прил
От: Cyberax Марс  
Дата: 10.08.07 22:12
Оценка: +1
Здравствуйте, adontz, Вы писали:

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

A>Если я такое захочу, то синглтон уже становится неприменим и никакой проблемы вобщем-то нет, потому что синглтона (или такой реализации синглтона) не будет.
Проблема будет, если ты захочешь это сделать в версии 1.1 продукта. Когда уже написаны мегабайты кода. Вот поэтому синглтон — по большей части и является антипаттерном.
Sapienti sat!
Re[5]: Singleton действительно антипаттерн в enterprize прил
От: IB Австрия http://rsdn.ru
Дата: 10.08.07 22:52
Оценка: +1
Здравствуйте, adontz, Вы писали:

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

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

A>Фабрика генерирует разные реализации интерфейса,

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

A> В Си++ чтобы синглтон нельзя было создать в обход фабричного метода ничего никуда заносить не надо.

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

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

Ну все, дальше без меня добъют..

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

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

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

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

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

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

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

Детали реализации тут не причем, просто смирись..
Мы уже победили, просто это еще не так заметно...
Re: Singleton действительно антипаттерн в enterprize приложе
От: _dmitri_  
Дата: 11.08.07 10:18
Оценка: :)
Здравствуйте, mr.sashich, Вы писали:

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

MS>Есть критерии использования этого паттерна, которые выверены на практике.

На практике, часто сталкиваюсь со следующей задачей:
    — Физически на машине присутствует одно устройство
    — Необходимо обеспечить доступ к нему из некоторого числа потоков
Самое простое решение использовать Singleton.
Из плюсов — очевидно простая реализация потокобезопасного обращения с устройством и
отсутсвие необходимости хранения потоком класса реализации устройства
Re[12]: Singleton действительно антипаттерн в enterprize при
От: adontz Грузия http://adontz.wordpress.com/
Дата: 11.08.07 11:03
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

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

C>А если просто понадобятся особые форматы вывода в лог?

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

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

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

Не, совсем ничего не использовать не выдет, надо использовать что-то вместо них. Вопрос в том что именно и насколько это оправдано.
Я согласен с IB, что stateful синглтон — зло, не согалсен что написать stateless — проблема.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Почему Singleton антипаттерн
От: Igor Trofimov  
Дата: 11.08.07 17:10
Оценка: +1
iT>>Значит, любой клас с конструктором — антипаттерн.
IB>А что, в любом классе конструктор занимается контролем количества экземпляров?

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

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

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

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

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

IB>И этих тоже нет.

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

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

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

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

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

IB>Выбирай, но осторожно, но выбирай.
Именно. Вешай ярлыки, но осторожно
Re[4]: Почему Singleton антипаттерн
От: IT Россия linq2db.com
Дата: 11.08.07 17:21
Оценка: +1
Здравствуйте, Igor Trofimov, Вы писали:

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

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

Плюсы/минусы остаются. Разница в том, что количество проблемных мест с этими плюсами/минусами резко сокращается, а в большинстве случаев стремится к нулю.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Re[18]: Singleton действительно антипаттерн в enterprize при
От: Cyberax Марс  
Дата: 11.08.07 17:58
Оценка: +1
Здравствуйте, adontz, Вы писали:

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

A>по-моему, ты перемудрил.
Не знаю. Просто stateless-объекты для меня больше похоже на нонсен.

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

A>Вообще-то синглтон затевался из-за глобальной точки доступа, так что называть глобальность недостатком достаточно странно.
Вот эта глобальность — и есть плохо. Я вообще предпочитаю всегда передавать все необходимые для вычисления данные в локальном контексте.
Sapienti sat!
Re[9]: Singleton действительно антипаттерн в enterprize прил
От: IB Австрия http://rsdn.ru
Дата: 11.08.07 19:45
Оценка: +1
Здравствуйте, 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... Осознаешь — приходи..
Мы уже победили, просто это еще не так заметно...
Re[12]: Singleton действительно антипаттерн в enterprize при
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.08.07 00:44
Оценка: :)
Здравствуйте, 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 реализация с автоматическим приведением типов, но эти сервисы надо где-то регистрировать и откуда-то брать. А когда начинаешь думать где регистрировать, откуда брать... Хорошо если есть главный объект-контейнер, а если нет такого объекта?
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[19]: Singleton действительно антипаттерн в enterprize при
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.08.07 08:47
Оценка: +1
Здравствуйте, minorlogic, Вы писали:

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

M>А я думал чтобы обеспечить единственность экземпляра.

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

Паттерн Singleton

Назначение

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

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

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



учи матчасть.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[3]: Почему Singleton антипаттерн
От: Константин Л. Франция  
Дата: 12.08.07 13:26
Оценка: :)
Здравствуйте, Cyberax, Вы писали:

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


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

C>А зачем они нужны? Типичное приложение можно построить без единой глобальной переменной.

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

КЛ>>А почему мы не знаем его текущее состояние? Че за лажа?

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

На Spring смотреть не охота, но верю на слово.
Re[4]: Почему Singleton антипаттерн
От: Cyberax Марс  
Дата: 12.08.07 13:39
Оценка: :)
Здравствуйте, Константин Л., Вы писали:

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

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

У меня, например, в GUI-приложении ровно 0 глобальных переменных в моем коде (что творится в библиотеках — я точно не знаю).
Sapienti sat!
Re[5]: Почему Singleton антипаттерн
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.08.07 14:00
Оценка: -1
Здравствуйте, Cyberax, Вы писали:

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


Извини, это прыжок в сторону. Если ты накидал на форму компоненты и обошлся без глобальных сущностей, это вовсе не означает, что их нет.
Любой аппаратный или разделяемый системный ресурс представляет собой глобальную сущность. У тебя всего одно сетевое соединение, а не по штучке на пакет, у тебя всего один принт-спулер, у тебя всего одно соединение с БД. Далеко не для всех из них надо городить синглтон. Я уже указывал, что синглтоны полезны когда мы хотим протащить сущность из верхнего слоя в нижний (или наоборот) минуя (не затрагивая) промежуточные слои. В остальных случаях IoC бывает достаточно. Но IoC через 4-5 слоёв абстрагирования это редкостный геморрой.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[4]: Почему Singleton антипаттерн
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.08.07 14:03
Оценка: +1
Здравствуйте, Константин Л., Вы писали:

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


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

P.S. На самом деле, чем больше Бодягин выставляет свою "мудрость" на показ, тем больше я в неё не верю. Имел счастье общаться с действительно хорошими педагогами, прямо скажем — другой стиль. Иван не плохой специалист, но как и всякий долго работавший, оброс субъективными предрассудками, которые, увы, любит выставлять истиной в последней инстанции.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[15]: Singleton действительно антипаттерн в enterprize при
От: WolfHound  
Дата: 12.08.07 14:28
Оценка: +1
Здравствуйте, adontz, Вы писали:

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

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

Короче ты можешь тут говорить что угодно но синглетон == глобальная переменная.
Различия косметические.
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Singleton действительно антипаттерн в enterprize при
От: WolfHound  
Дата: 12.08.07 14:28
Оценка: +1
Здравствуйте, 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...
... << RSDN@Home 1.2.0 alpha rev. 673>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Почему Singleton антипаттерн
От: adontz Грузия http://adontz.wordpress.com/
Дата: 12.08.07 14:48
Оценка: :)
Здравствуйте, 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 делать заранее — то потом добавление еще одного параметра делается легко и безболезненно. А в существующее приложение, действительно, приходится иногда вставлять синглтоновые хаки.


Никогда в проекте ты не сможешь задействовать сторонние библиотеки полностью удовлетворяющие все твои фантазии.
A journey of a thousand miles must begin with a single step © Lau Tsu
Re[18]: Singleton действительно антипаттерн в enterprize при
От: adontz Грузия http://adontz.wordpress.com/
Дата: 13.08.07 08:29
Оценка: :)
Здравствуйте, IB, Вы писали:

IB>Давай рассмотрим простой сценарий: Есть интерфейс фабричного метода, задача которого конструировать объект логгирования. Есть две разные реализации этого интерфейса, одна инициализирует объект логгирования одним именем файла лога, другая — другм. При этом объект один и тот же — Log. Является ли это паттерном Factory Method или нет? И если нет, то как зазывается этот паттерн?


Если объекты Log используются клиентским кодом как есть, а не через какой-то интерфейс (ILog), то это не Factory Method, а просто метод возвращающий объект и никакого паттерна тут нет.

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


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

A>> Честно говоря, я давно подозреваю, что ты осознаёшь свою неправоту, но не хочешь признаваться.

IB>Да хватит уже дешевых лозунгов, Рома..

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

A>>
  • Product (Document) — продукт:
    A>>- определяет интерфейс объектов, создаваемых фабричным методом;
    IB>Если этот интерфейс выражается одним конкретным классом — это уже не Factory Method?

    Тип не может быть классом и одновременно своим же подклассом, так что ответ на твой вопрос — нет. Я вообще представляю себе всю бредовость ситуации если бы ответ был да, ведь тогда мы бы могли назвать int operator+(int, int) фабричным методом порождающим разные int'ы.
  • A journey of a thousand miles must begin with a single step © Lau Tsu
    Re: Почему Singleton антипаттерн
    От: the_dip Таджикистан  
    Дата: 13.08.07 10:48
    Оценка: :)
    Здравствуйте, IB, Вы писали:

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

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

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

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

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

    Ну и что? Какие *практические* последствия это имеет? Чтобы выявить все зависимости, достаточно текстового поиска по коду. Если зависимость имеет критическое значение, ее можно (и нужно) отразить в комментариях.

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

    Не совсем так. Например, в C++ можно тест сделать friend-ом синглтона, открыв тесту доступ к приватному конструктору синглтона. Тогда тест сможет самостоятельно создавать "свеженькие" синглтоны в любом нужном количестве.

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

    Ну так там сказано четко overuse, а не use.
    Re[2]: Почему Singleton антипаттерн
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 13:03
    Оценка: :)
    Здравствуйте, Ужасть бухгалтера, Вы писали:

    УБ>ИМХО, лучше просто трезво оценивать возможную область применения синглтона, его плюсы/минусы и возможные альтернативы. А то из-за ожесточенного флейма в этой ветке возникает впечатление, что некоторые зачем-то пытаются свести использование синглтона вообще к нулю.


    Охотники на ведь всегда были есть и будут. Главное помнить, что у каждой ведьмы есть внучка — девочка Таня и она объязательно отомстит программисту под новый год.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[4]: Почему Singleton антипаттерн
    От: Igor Trofimov  
    Дата: 13.08.07 16:20
    Оценка: :)
    КЛ>На Spring смотреть не охота, но верю на слово.

    Лучше посмотри А то сейчас тебе тут наговорят, а ты и возразить аргументированно не сможешь
    Re[4]: Почему Singleton антипаттерн
    От: IT Россия linq2db.com
    Дата: 13.08.07 19:55
    Оценка: +1
    Здравствуйте, adontz, Вы писали:

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


    Ну давай на примере, если не убедительно.

    public class MyClass : MyBaseClass
    {
      void MyMethod()
      {
        IMyService service = ServiceProvider.GetService<IMyService>();
        if (service != null)
            service.DoSome();
      }
    }

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

    public class MyClass : MyBaseClass
    {
      void MyMethod()
      {
        Singleton<MyService>.Instance.DoSome();
      }
    }

    Что тебе нужно сделать, чтобы этот код заработал на клиенте и при этом не надо было тянуть с собой имплементацию MyService?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[5]: Почему Singleton антипаттерн
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 20:01
    Оценка: :)
    Здравствуйте, IT, Вы писали:

    IT>Ну давай на примере, если не убедительно.


    Вот теперь убедительно, спасибо.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[24]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 20:39
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    A>>Я что-то совсем не понял зачем тебе дерево. Можно примерчик простенький?

    WH>Я уже раз 10 написал.
    WH>Ладно еще раз:
    WH>Запускаем сервер.
    WH>Создаем логгер.
    WH>Подключаются несколько пользователей. Для каждого создается сессия.
    WH>Для каждой сессии при выводе в лог нужно добавить некий UID сессии.
    WH>Сесии обрабатываются паралельно.

    Я просто не очень понимаю, какая разница что таскать за собой: специфический логгер или идентификатор сессии.
    void method(service_provider sp)
    {
      sp.get_service<logger>.log("text");
    }
    
    void method(session_id id)
    {
      singleton<logger>.instance(id).log("text");
    }

    То есть в чём твоя глобальная выгода? В том что ты не указываешь id явно?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[26]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 14.08.07 09:16
    Оценка: :)
    Здравствуйте, WolfHound, Вы писали:

    WH>Кошмар! Точно кто-то сильно накосячил.


    Да нет, всё нормально. просто ты пока, наверное, не вкурил...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Singleton действительно антипаттерн в enterprize приложения?
    От: mr.sashich  
    Дата: 09.08.07 13:30
    Оценка:
    Я понимаю, что тема возможно избита, но все же у кого какие мысли?
    Есть критерии использования этого паттерна, которые выверены на практике.
    Только не надо копировать описание синопсиса этого паттерна из "Розовой книжки по Java".
    Это будет лишнее =)
    Re[4]: Singleton действительно антипаттерн в enterprize прил
    От: mr.sashich  
    Дата: 10.08.07 05:13
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

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

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

    S>Лично меня всегда такие схемы напрягали, потому что совершенно не видно, кто кого использует, и откуда что берется. Прямо как в анекдоте:

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

    А если IoC контейнер не используется как подсунуть одно "окно" не используя сингелтон?
    Re[5]: Singleton действительно антипаттерн в enterprize прил
    От: IB Австрия http://rsdn.ru
    Дата: 10.08.07 07:39
    Оценка:
    Здравствуйте, mr.sashich, Вы писали:

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

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

    Почитай подробнее про IServiceProvider, например здесь: Lightweight Containers and Plugin Architectures: Dependency Injection and Dynamic Service Locators in .NET
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Мы уже победили, просто это еще не так заметно...
    Re[3]: Singleton действительно антипаттерн в enterprize прил
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 10.08.07 14:11
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    ты подсунешь мок? Или Instance — property, которая реализует фабрику?
    Re[5]: Singleton действительно антипаттерн в enterprize прил
    От: IB Австрия http://rsdn.ru
    Дата: 10.08.07 14:48
    Оценка:
    Здравствуйте, IT, Вы писали:

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

    Ну это уж, извиняюсь, особенности реализации конкретной дырки..
    Понятно, что кривой реализацией можно самую красивую идею испохабить, хотя конечно ISP не самый очевидный паттерн, со своими нюансами...
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Мы уже победили, просто это еще не так заметно...
    Re[4]: Singleton действительно антипаттерн в enterprize прил
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 10.08.07 16:57
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


    Синглтон лучше класса со статическими методами двумя вещами: отложенной инициализацией и возможностью реализовать интерфейс.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[5]: Singleton действительно антипаттерн в enterprize прил
    От: Cyberax Марс  
    Дата: 10.08.07 17:05
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

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

    Интерфейс — это уже интереснее. Но я слабо представляю когда это нужно.
    Sapienti sat!
    Re[6]: Singleton действительно антипаттерн в enterprize прил
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 10.08.07 17:19
    Оценка:
    Здравствуйте, 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 и т.п. Естественно, что для того кто использует синглтон это должно быть скрыто. Интерфейсы тут помогают.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[7]: Singleton действительно антипаттерн в enterprize прил
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 10.08.07 17:24
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    Т.е. реализуем фабрику вместе с синглтоном и приписываем её свойства синглтону, не знаю что и сказать
    Re[5]: Singleton действительно антипаттерн в enterprize прил
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 10.08.07 17:26
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    К>>Довольно странное утверждение...

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

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


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

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


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

    A>
    A>Singleton<IMyService>.Instance;
    A>

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

    A>и возвращать разные реализации IMyService в зависимости от того находимся ли мы в режиме тестирования или нет.

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

    Понятно — подменяем понятия...
    Re[6]: Singleton действительно антипаттерн в enterprize прил
    От: IT Россия linq2db.com
    Дата: 10.08.07 17:59
    Оценка:
    Здравствуйте, IB, Вы писали:

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

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

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

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


    Если с хорошим паттерном возникают плохие проблемы с завидной регулярностью, то усомниться стоит прежде всего в хорошести паттерна. Хороший паттерн должен быть дуракоустойчив.
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[7]: Singleton действительно антипаттерн в enterprize прил
    От: IB Австрия http://rsdn.ru
    Дата: 10.08.07 18:42
    Оценка:
    Здравствуйте, IT, Вы писали:

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

    Не знаю, мне пока все больше удачные реализации попадались..
    Мы уже победили, просто это еще не так заметно...
    Re[8]: Singleton действительно антипаттерн в enterprize прил
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 10.08.07 21:43
    Оценка:
    Здравствуйте, Курилка, Вы писали:

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


    Я ничего синглтону не приписывал, я просто показал зачем может в принципе понадобится реализовывать интерфейс.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[4]: Singleton действительно антипаттерн в enterprize прил
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 10.08.07 21:57
    Оценка:
    Здравствуйте, IB, Вы писали:

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


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

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

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

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

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


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

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


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

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


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

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

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

    Забавно. Вот, например, SQL сервер работает с файлами, но в публичном контракте ADO этого не видно. Обидно. Как же они так, а? А может твоя аксиома неправильная и детали реализации не должны торчать наружу?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[10]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 10.08.07 22:18
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


    Если у меня вдруг, внезапно появятся кодировки, когда их раньше не было, это уже вызовет достаточно большое переписывание кода.
    На мой взгляд твой пример вообще не удачен и такие вопросы решаются в процессе конфигурации, а не использования.
    И, опять таки, критикуешь — предложи что-то лучше.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[7]: Singleton действительно антипаттерн в enterprize прил
    От: IB Австрия http://rsdn.ru
    Дата: 11.08.07 07:48
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

    A>Тем не менее, это всё же реализация интерфейса.

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

    A>Синглтон тоже может, но не объязан, фабрика объязана.

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

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

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

    A>Нет состояния.

    Рома, это мантра, а мантры, к сожалению, не работают на окружающую действительность. От того, что ты себя убедишь в отсутствии состояния, оно все равно никуда не денется. И это состояние будут пихать в синглтоны, сколько бы ты не кричал, что это не правильно.
    Мы уже победили, просто это еще не так заметно...
    Re[11]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 11.08.07 09:14
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    А если просто понадобятся особые форматы вывода в лог?

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

    A>И, опять таки, критикуешь — предложи что-то лучше.
    Так было уже предложено — не использовать синглтоны.
    Sapienti sat!
    Re: Почему Singleton антипаттерн
    От: Igor Trofimov  
    Дата: 11.08.07 09:45
    Оценка:
    IB>1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров.

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

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


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

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


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

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


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

    А с IoC-контроллерами своя беда — возрастает сложность (и вероятность ошибок) в нсатройке и корректном соединении всех компонентов.
    Re[2]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 11.08.07 10:07
    Оценка:
    Здравствуйте, Igor Trofimov, Вы писали:

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

    А что, в любом классе конструктор занимается контролем количества экземпляров?

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

    Этих нет, без типа.

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

    И этих тоже нет.

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

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

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

    Выбирай, но осторожно, но выбирай.
    Мы уже победили, просто это еще не так заметно...
    Re[8]: Singleton действительно антипаттерн в enterprize прил
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.08.07 10:54
    Оценка:
    Здравствуйте, 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>Рома, это мантра, а мантры, к сожалению, не работают на окружающую действительность.

    Не, мантра это то что все зависимости должны торчать наружу. Люди годами инкапсулировали, а пришёл добрый дядя Ваня и раскапсулировал всё нафиг, потому что нефиг
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[2]: Singleton действительно антипаттерн в enterprize прил
    От: _dmitri_  
    Дата: 11.08.07 11:35
    Оценка:
    Что-то вроде следующего:


    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(...)
    }
    Re[3]: Почему Singleton антипаттерн
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.08.07 13:02
    Оценка:
    Здравствуйте, IB, Вы писали:

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


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

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


    Зачем осторожно? Шило на мыло меняешь, выходит, если опять осторожно надо.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[4]: Singleton действительно антипаттерн в enterprize прил
    От: Константин Л. Франция  
    Дата: 11.08.07 13:23
    Оценка:
    Здравствуйте, 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 здесь не причем, а во-вторых, я предлагал это как решение ровно для тех задачь, где есть в этом потребность. Читай внимательно, прежде чем критиковать бросаться..
    Re[5]: Singleton действительно антипаттерн в enterprize прил
    От: Cyberax Марс  
    Дата: 11.08.07 13:27
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

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

    Про IoC (он же "dependency injection") ты слышал?
    Sapienti sat!
    Re: Почему Singleton антипаттерн
    От: Константин Л. Франция  
    Дата: 11.08.07 13:31
    Оценка:
    Здравствуйте, 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()
    }


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

    []
    Re[9]: Singleton действительно антипаттерн в enterprize прил
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.08.07 13:55
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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

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

    maintains — есть, changes — нет.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[2]: Почему Singleton антипаттерн
    От: Cyberax Марс  
    Дата: 11.08.07 14:00
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

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

    А зачем они нужны? Типичное приложение можно построить без единой глобальной переменной.

    КЛ>А почему мы не знаем его текущее состояние? Че за лажа?

    КЛ>Зависимость? ну так строй все на интерфейсах. Совсем уйти от зависимости тебе и IServiceProvider не поможет.
    Поможет. Можешь посмотреть, например, на Spring — как там задают зависимости с помощью внешнего конфига.
    Sapienti sat!
    Re[10]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 11.08.07 14:44
    Оценка:
    Здравствуйте, 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?
    Sapienti sat!
    Re[12]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 11.08.07 15:13
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    A>Если ты про System.String из .Net Framework, то да, буду.
    Мда.

    A>У тебя есть другое определение? Поделись.

    Есть. Stateless = не имеющий состояния. Любой stateless-объект может быть заменен на любой другой объект (того же класса, естественно) без изменения поведения.
    Sapienti sat!
    Re[7]: Singleton действительно антипаттерн в enterprize прил
    От: Cyberax Марс  
    Дата: 11.08.07 15:27
    Оценка:
    Здравствуйте, IT, Вы писали:

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

    C>>Про IoC (он же "dependency injection") ты слышал?
    IT>А кто тебе будет впрыскивать?
    Внешняя система конфигурации, например.
    Sapienti sat!
    Re[7]: Singleton действительно антипаттерн в enterprize прил
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.08.07 15:54
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    Всё, обычно, заканчивается тем, что у списка параметров каждого метода есть префикс — кортёж впрыснутых зависимостей. Ну и на счастье Ивана во внешнем интерфейсе есть все зависимости. ИМХО это и есть антипаттерн.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[13]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.08.07 15:57
    Оценка:
    Здравствуйте, 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.

    — в самую точку.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[8]: Singleton действительно антипаттерн в enterprize прил
    От: IT Россия linq2db.com
    Дата: 11.08.07 16:05
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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

    C>Внешняя система конфигурации, например.

    Что значит внешняя? Внешняя по отношению к чему? И почему внутренняя уже не канает?
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[14]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 11.08.07 16:05
    Оценка:
    Здравствуйте, 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: блин, это ты удалил прошлое сообщение? Я как раз на него отвечал.
    Sapienti sat!
    Re[9]: Singleton действительно антипаттерн в enterprize прил
    От: Cyberax Марс  
    Дата: 11.08.07 16:07
    Оценка:
    Здравствуйте, IT, Вы писали:

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

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

    IT>И почему внутренняя уже не канает?

    Можно и внутреннюю — то есть тупо передавать нужные параметры в конструктор.
    Sapienti sat!
    Re[10]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 11.08.07 16:27
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

    IT>>И почему внутренняя уже не канает?

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

    Кто их должен передавать?
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[11]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 11.08.07 16:37
    Оценка:
    Здравствуйте, IT, Вы писали:

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

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

    IT>>>И почему внутренняя уже не канает?

    C>>Можно и внутреннюю — то есть тупо передавать нужные параметры в конструктор.
    IT>Кто их должен передавать?
    Объект, создающий данный объект.
    Sapienti sat!
    Re[12]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 11.08.07 17:10
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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

    C>Как угодно. Например, ты можешь его положить в theadlocal-переменную, впрыскивать его в объекты или передавать явно.

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

    IT>>>>И почему внутренняя уже не канает?

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

    А кто будет создавать объект, создающий данный объект?
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[16]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 11.08.07 17:28
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

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

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

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

    A>Какие например? Методы можно дёргать откуда угодно и в любом порядке, какие тут могут быть проблемы?
    Глобальность.
    Sapienti sat!
    Re[13]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 11.08.07 17:31
    Оценка:
    Здравствуйте, IT, Вы писали:

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

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

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

    C>>Объект, создающий данный объект.
    IT>А кто будет создавать объект, создающий данный объект?
    Объект, который будет создавать объект, который будет создавать объект. И так рекурсивно до функции main().
    Sapienti sat!
    Re[17]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.08.07 17:54
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

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


    Вообще-то синглтон затевался из-за глобальной точки доступа, так что называть глобальность недостатком достаточно странно.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[4]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 11.08.07 20:05
    Оценка:
    Здравствуйте, Igor Trofimov, Вы писали:

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

    Ну тебе-то, надеюсь, не надо разжевывать, что означает слово "контроль"?

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

    Нет, не будет.

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

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

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

    Минусов заметно меньше.

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

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

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

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

    iT>Именно. Вешай ярлыки, но осторожно

    Можешь привести цитату, где я повесил на синглтон ярлык?
    Мы уже победили, просто это еще не так заметно...
    Re[10]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 11.08.07 22:04
    Оценка:
    Здравствуйте, 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 это не паттерн, хотя вряд ли ты это понимаешь...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[11]: Singleton действительно антипаттерн в enterprize при
    От: IB Австрия http://rsdn.ru
    Дата: 11.08.07 23:45
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    Известно чего..

    A>лишь бы не признать своей неправоты.

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

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

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

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

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

    A>Я по крайне мере умею читать

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

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

    Остаюсь верен себе, просто называю вещи своими именами..

    A> а когда фабричного метода довольно свободно трактуешь.

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

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

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

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

    Доступ к приватным полям тебя не смущает? А кто тут дефирамбы инкапсуляции пел?

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

    "- Малчик?
    — Нет.
    — А кто?!!"
    Ок, буквоед ты наш, назови это "архитектурный принцип", на вопрос-то можешь ответить?
    Мы уже победили, просто это еще не так заметно...
    Re[13]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 12.08.07 02:17
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    А так?

    void level3()
    {
        log.log("level 3!");
    }
    void level2()
    {
        level3();
    }
    void level1()
    {
        level2();
    }
    
    logger log;
    
    int main(logger pLog)
    {
        log = pLog;
        level1();
    }
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[18]: Singleton действительно антипаттерн в enterprize при
    От: minorlogic Украина  
    Дата: 12.08.07 07:47
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


    А я думал чтобы обеспечить единственность экземпляра. Ну вот , могу предложить все данные объявлять глобальными. Столько преимуществ, доступ из любой точки программы. !!!
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Ищу работу, 3D, SLAM, computer graphics/vision.
    Re: Почему Singleton антипаттерн
    От: minorlogic Украина  
    Дата: 12.08.07 07:54
    Оценка:
    Здравствуйте, IB, Вы писали:

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

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


    P,S, Сингелтоны не использую и не защищаю .
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Ищу работу, 3D, SLAM, computer graphics/vision.
    Re[14]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 08:44
    Оценка:
    Здравствуйте, 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 будут в разных единицах компиляции и иметь общую глобальную переменную им не светит.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[20]: Singleton действительно антипаттерн в enterprize при
    От: minorlogic Украина  
    Дата: 12.08.07 09:03
    Оценка:
    Похоже что ты даже то что сам написал не читаеш. Прочти еще раз назначение патерна.

    И ты серьезно считаешь что доступность можно обеспечить только через глобальность ? Учи матчасть , примерно с основ структурного програмирования.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Ищу работу, 3D, SLAM, computer graphics/vision.
    Re[21]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 09:39
    Оценка:
    Здравствуйте, minorlogic, Вы писали:

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


    Нет не думаю, это твои бредовые слова не мои. Доступно можно ещё, например, через broadcast сообщения о поиске обеспечить (если конечно есть некоторая общедоступная система обмена сигналами).
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[22]: Singleton действительно антипаттерн в enterprize при
    От: minorlogic Украина  
    Дата: 12.08.07 11:04
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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


    Тогда прочти предыдущий свой пост , где ты пишешь про голобальность.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Ищу работу, 3D, SLAM, computer graphics/vision.
    Re[23]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 11:10
    Оценка:
    Здравствуйте, minorlogic, Вы писали:

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


    И что там не так?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[14]: Singleton действительно антипаттерн в enterprize при
    От: Константин Л. Франция  
    Дата: 12.08.07 13:39
    Оценка:
    Здравствуйте, 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>


    А это, пардон, откуда? Да и разницы особой не вижу
    Re[6]: Singleton действительно антипаттерн в enterprize прил
    От: Константин Л. Франция  
    Дата: 12.08.07 14:19
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

    C>Про IoC (он же "dependency injection") ты слышал?

    только что прочел, что это такое. идея, оказывается не нова. а во что я думаю по этому поводу хорошо прднмонстрировал IT в последующих "вопросах" тебе.
    Re[6]: Почему Singleton антипаттерн
    От: Cyberax Марс  
    Дата: 12.08.07 14:20
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

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

    A>Любой аппаратный или разделяемый системный ресурс представляет собой глобальную сущность.

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

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

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

    C чего ты взял?

    A>у тебя всего одно соединение с БД.

    С чего ты взял?

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

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

    Если IoC делать заранее — то потом добавление еще одного параметра делается легко и безболезненно. А в существующее приложение, действительно, приходится иногда вставлять синглтоновые хаки.
    Sapienti sat!
    Re[16]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 15:14
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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


    Из DLL ок?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[14]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 15:21
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Жду решение на синглетоне...

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

    Во-первых, ты подменил задачу, так что никакого решения на синглтоне не будет. Задача подмены сервисов изначально не стояла.
    Во-вторых, представь что level2 и level3 менять нельзя (библиотечный код, причём не твой). Очень интересно как тебе помогут сервисы...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[5]: Почему Singleton антипаттерн
    От: Константин Л. Франция  
    Дата: 12.08.07 15:40
    Оценка:
    Здравствуйте, adontz, Вы писали:

    []

    да и мы иногда страдаем, чего греха таить
    Re[15]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 12.08.07 15:55
    Оценка:
    Здравствуйте, 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 будут в разных единицах компиляции и иметь общую глобальную переменную им не светит.

    Ну так ты тогда и приведи пример с разными единицами.
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[15]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 12.08.07 15:55
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

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


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

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


    Здрасьте. Рома больше всего протестует по причине наличия у всей цепочки вызываемых методов дополнительного параметра. Скажу тебе по секрету. Такие параметры элементарно убираются и никаких проблем не вызывают.
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[15]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 12.08.07 15:59
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

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

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

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

    А теперь всетки попробуй предоставить решение на синглетоне... да у нас уже есть 10 метров кода... использующие синглетон.
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[17]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 12.08.07 15:59
    Оценка:
    Здравствуйте, 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 не знает.
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[8]: Почему Singleton антипаттерн
    От: Cyberax Марс  
    Дата: 12.08.07 16:15
    Оценка:
    Здравствуйте, 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.
    Sapienti sat!
    Re[16]: Singleton действительно антипаттерн в enterprize при
    От: Константин Л. Франция  
    Дата: 12.08.07 16:23
    Оценка:
    Здравствуйте, IT, Вы писали:

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


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


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


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

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


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


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

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

    Ну да ладно, полезность dep. inj. никто не оспаривает. Никто особо и не оспаривает наличие проблем у синглтона. Но вот устраивать охоту на ведьм и делать из IoC пришествие Христа тоже не рулез.
    Re[16]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 16:34
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

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

    WH>В случае с Dependency injection проблем не возникает, а вот как такое провернуть на синглетонах...

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

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


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

    Кроме того, был опущен вопрос времени жизни. В случае с сервисами я объязан их все создать заранее, просто чтобы зарегистрировать у провайдера, в случае с синглтонами ненужной инициализации нет. Конечно, можно всё обернуть в Lazy Initialization, но это уже больше похоже на костыли...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[17]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 12.08.07 16:39
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

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


    Только не в контексты, а в конструкторы или инициализаторы объектов.
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[17]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 12.08.07 16:47
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

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

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

    Больше и не нужно.

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

    Ни разу со временем жизни проблем не возникало.

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

    Я вот не помню ни одного случая когда отложенная инициализация имела смысл.
    У меня постоянно получается что момент создания/разрушения сервисов строго определен.
    Что я делаю не так?
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[17]: Singleton действительно антипаттерн в enterprize при
    От: Константин Л. Франция  
    Дата: 12.08.07 16:59
    Оценка:
    Здравствуйте, adontz, Вы писали:

    []

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


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

    []
    Re[18]: Singleton действительно антипаттерн в enterprize при
    От: Константин Л. Франция  
    Дата: 12.08.07 17:03
    Оценка:
    Здравствуйте, IT, Вы писали:

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


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


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


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

    Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
    Re[19]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 12.08.07 17:09
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

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

    КЛ>А это можно было и не говорить.
    КЛ>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
    То есть, у тебя все объекты имеют пустые конструкторы? Ведь почти любой параметр в конструкторе — деталь реализации.
    Sapienti sat!
    Re[20]: Singleton действительно антипаттерн в enterprize при
    От: Константин Л. Франция  
    Дата: 12.08.07 17:15
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

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

    ну что за манера все доводить до абсурда?
    Re[19]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 12.08.07 17:17
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

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


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


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

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


    А в чём проблема?
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[20]: Singleton действительно антипаттерн в enterprize при
    От: Константин Л. Франция  
    Дата: 12.08.07 17:28
    Оценка:
    Здравствуйте, IT, Вы писали:

    []

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


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


    а видимо в том, что есть случаи когда это просто не нужно
    Re[3]: Почему Singleton антипаттерн
    От: Константин Л. Франция  
    Дата: 12.08.07 17:29
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

    C>А зачем они нужны? Типичное приложение можно построить без единой глобальной переменной.

    КЛ>>А почему мы не знаем его текущее состояние? Че за лажа?

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

    дык, библиотеки и прикладной код это две разные вещи.
    Re[4]: Почему Singleton антипаттерн
    От: Cyberax Марс  
    Дата: 12.08.07 17:57
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

    C>>Поможет. Можешь посмотреть, например, на Spring — как там задают зависимости с помощью внешнего конфига.

    КЛ>дык, библиотеки и прикладной код это две разные вещи.
    И что? От библиотеки все что требуется — уметь передавать контекст. Бывают исключения, но уж очень редко.
    Sapienti sat!
    Re[13]: Singleton действительно антипаттерн в enterprize при
    От: IB Австрия http://rsdn.ru
    Дата: 12.08.07 18:53
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    Ну, то есть, это я виноват, что ты даже не читаешь, что цитируешь..

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

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

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

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

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

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

    A>Где тут доступ к приватным полям?

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

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



    Предчувствуя бурную дискуссию, мало связанную с синглтоном, предлагаю вынести это дело в отдельный топик. На днях сформулирую, там и обсудим...
    Мы уже победили, просто это еще не так заметно...
    Re[4]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 12.08.07 19:05
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

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


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

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

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

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

    Хм.. У людей с адекватной самооценкой мой стиль изложения почему-то не вызывает негативной реакции. И то, что ты повел себя как нашкодивший ученик, говорит совсем не в твою пользу..
    Мы уже победили, просто это еще не так заметно...
    Re[18]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 19:13
    Оценка:
    Здравствуйте, 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 минуты потому что программист не стал заморачиваться и решил инициализировать всё сразу.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[21]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 12.08.07 19:16
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

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

    КЛ>>>Но вот нафига мне раскрывать в публичном интерфейсе, что для деталей реализации мне нужно еще что-то.
    C>>То есть, у тебя все объекты имеют пустые конструкторы? Ведь почти любой параметр в конструкторе — деталь реализации.
    КЛ>ну что за манера все доводить до абсурда?
    Чтобы показать абсурдность твоей идеи.
    Sapienti sat!
    Re[20]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 19:17
    Оценка:
    Здравствуйте, IT, Вы писали:

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

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

    В том что если у тебя есть уровень1 в котором настраивается сущность, уровень2 которому на сущность начхать и уровень3 который использует сущность, то в результате изменения сущности надо переписывать уровень2.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[14]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 19:21
    Оценка:
    Здравствуйте, IB, Вы писали:

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


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

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

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

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

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

    речь о порождаемой иерархии.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[5]: Почему Singleton антипаттерн
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 19:22
    Оценка:
    Здравствуйте, IB, Вы писали:

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


    Адекватная — это когда человек думает, что он глупее тебя? Я, в таком случае, чрезвычайно неадекватен.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[15]: Singleton действительно антипаттерн в enterprize при
    От: Cyberax Марс  
    Дата: 12.08.07 19:26
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    A>Ой, ну кто бы говорил. Ты себе аватарчик с нимбом уже заказал?
    Так он уже победил, просто это еще не так заметно
    Sapienti sat!
    Re[15]: Singleton действительно антипаттерн в enterprize при
    От: IB Австрия http://rsdn.ru
    Дата: 12.08.07 20:07
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    Зачем аватарчик, у меня нормальный есть.. )

    A>

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

    A>речь о порождаемой иерархии.
    Одаренный ты наш, речь о порождаемом объекте и порождающей иерархии.
    Мы уже победили, просто это еще не так заметно...
    Re[16]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 12.08.07 21:38
    Оценка:
    Здравствуйте, IB, Вы писали:

    A>>

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

    A>>речь о порождаемой иерархии.
    IB>Одаренный ты наш, речь о порождаемом объекте и порождающей иерархии.

    Всё, последняя попытка. Если и после этого ты опять не поймёшь, что Factory Method, в отличие от Singleton, обязан создавать объекты реализующие некоторый интерфейс, то ты просто упрямец, готовый говорить любую чушь, лишь бы не сказать страшненьких (для тебя) слов "я был не прав". Честно говоря, я давно подозреваю, что ты осознаёшь свою неправоту, но не хочешь признаваться.

    Участники

    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[7]: Почему Singleton антипаттерн
    От: Cyberax Марс  
    Дата: 12.08.07 22:43
    Оценка:
    Здравствуйте, IT, Вы писали:

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

    IT>Рома, ты — неадекватен.
    По выразительности может соперничать с: "Борис, ты не прав" и "Она утонула"
    Sapienti sat!
    Re[8]: Почему Singleton антипаттерн
    От: Константин Б. Россия  
    Дата: 13.08.07 02:37
    Оценка:
    Здравствуйте, Cyberax, Вы писали:

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


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

    IT>>Рома, ты — неадекватен.
    C>По выразительности может соперничать с: "Борис, ты не прав" и "Она утонула"
    Настоящий шедевр все-таки здесь Re[48]: Являются ли макросы свидетельством недостаточной выр
    Автор: IT
    Дата: 08.08.07
    =)
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[17]: Singleton действительно антипаттерн в enterprize при
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 07:56
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Всё, последняя попытка.

    Что-то ты быстро сдаешься, я только во вкус входить начал..

    A> Если и после этого ты опять не поймёшь, что Factory Method, в отличие от Singleton, обязан создавать объекты реализующие некоторый интерфейс,

    Давай рассмотрим простой сценарий: Есть интерфейс фабричного метода, задача которого конструировать объект логгирования. Есть две разные реализации этого интерфейса, одна инициализирует объект логгирования одним именем файла лога, другая — другм. При этом объект один и тот же — Log. Является ли это паттерном Factory Method или нет? И если нет, то как зазывается этот паттерн?

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

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

    A> Честно говоря, я давно подозреваю, что ты осознаёшь свою неправоту, но не хочешь признаваться.

    Да хватит уже дешевых лозунгов, Рома..

    A>
  • Product (Document) — продукт:
    A>- определяет интерфейс объектов, создаваемых фабричным методом;
    Если этот интерфейс выражается одним конкретным классом — это уже не Factory Method?
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
  • Мы уже победили, просто это еще не так заметно...
    Re[6]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 07:56
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Адекватная — это когда человек думает, что он глупее тебя?

    Адекватная — это когда человек не мыслит категориями "умнее/глупее" при оценке технического текста..

    A> Я, в таком случае, чрезвычайно неадекватен.

    +1
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Мы уже победили, просто это еще не так заметно...
    Re[15]: Singleton действительно антипаттерн в enterprize при
    От: AndrewJD США  
    Дата: 13.08.07 08:36
    Оценка:
    Здравствуйте, adontz, Вы писали:


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


    А потом ее поставили, а у нас все на синглетонах. Нежданчик?
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[5]: Почему Singleton антипаттерн
    От: Константин Л. Франция  
    Дата: 13.08.07 08:37
    Оценка:
    Здравствуйте, IB, Вы писали:

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


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

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

    Ну, знаешь, увольте...

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

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

    Хм... Спросить что? Спросить какие есть проблемы с получением статуса? Не смеши меня.

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

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

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

    ууу... Поперло дело...
    Re[16]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 08:51
    Оценка:
    Здравствуйте, AndrewJD, Вы писали:

    AJD>А потом ее поставили, а у нас все на синглетонах. Нежданчик?


    Я уже привёл решение не требующее переписывания клиентов.
    http://www.rsdn.ru/Forum/Message.aspx?mid=2618283&amp;only=1
    Автор: adontz
    Дата: 12.08.07
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[19]: Singleton действительно антипаттерн в enterprize при
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 09:05
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Если объекты Log используются клиентским кодом как есть, а не через какой-то интерфейс (ILog), то это не Factory Method,

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

    A> а просто метод возвращающий объект и никакого паттерна тут нет.

    "More generally, the term factory method is often used to refer to any method whose main purpose is creation of objects."
    Как видишь, по мнению википедии, такая конструкция так же имеет право называться фабричным методом.

    A>А у меня нет цели убедить тебя, что ты не прав.

    Ну тогда и не переживай так..

    A> Я закинул в форум альтернативное мнение и только.

    В чем альтернатива-то?

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

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

    A>Тип не может быть классом и одновременно своим же подклассом, так что ответ на твой вопрос — нет.

    То есть, пока я не начну в сабклассе фабрики возвращать именно наследника создаваемого объекта — это не будет фабричным методом?
    Не кажется ли тебе, что ты довольно узко смотришь на паттерн?
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Мы уже победили, просто это еще не так заметно...
    Re[6]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 09:05
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

    КЛ>Ну, знаешь, увольте...

    Хорошо, свободен..
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Мы уже победили, просто это еще не так заметно...
    Re[8]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 09:05
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

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

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

    Re[6]: Почему Singleton антипаттерн
    Автор: IT
    Дата: 13.08.07
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Мы уже победили, просто это еще не так заметно...
    Re[20]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 09:16
    Оценка:
    Здравствуйте, IB, Вы писали:

    A>>Если объекты Log используются клиентским кодом как есть, а не через какой-то интерфейс (ILog), то это не Factory Method,

    IB>То есть, в языках, в которых не предусмотрено явно выделенной сущности для декларации публичного контракта паттерн Factory Method не возможен?

    Я не понял твой мысли о явности, приведи пример языка и кода.

    IB>"More generally, the term factory method is often used to refer to any method whose main purpose is creation of objects."

    IB>Как видишь, по мнению википедии, такая конструкция так же имеет право называться фабричным методом.

    Я с этим мнением не согласен и считаю правильным классическое определение. Вопросы?

    A>> Я закинул в форум альтернативное мнение и только.

    IB>В чем альтернатива-то?

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

    IB>Подумай над этим, и не провоцируй лишний раз..


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

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


    Верно.

    IB>Не кажется ли тебе, что ты довольно узко смотришь на паттерн?


    Я не вижу смысла в указанном тобой расширении. Если признать твою точку зрения верной, то любой метод возвращающий не один и тот же объект станет фабричным. Все методы поделятся на instance-accessor'ы синглтонов и фабричные. Это не совсем то, что я считаю правильным. Собственно, это по меньшей мере странно.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[7]: Почему Singleton антипаттерн
    От: Константин Л. Франция  
    Дата: 13.08.07 09:18
    Оценка:
    Здравствуйте, IB, Вы писали:

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


    КЛ>>Ну, знаешь, увольте...

    IB>Хорошо, свободен..

    спасибо, можно идти?
    Re[9]: Почему Singleton антипаттерн
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 09:19
    Оценка:
    Здравствуйте, IB, Вы писали:

    IB>Не начинай играть в "кто первый начал", сольешь сразу.


    Я теперь играю в игру "кто не смог остановиться".

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

    IB>Re[6]: Почему Singleton антипаттерн
    Автор: IT
    Дата: 13.08.07


    Опять личный наезд? А можно наконец-то что-то услышать про синглтон? Вот Cyberax, Wolfhound хоть что-то по делу говорят, а ты всё вокруг моей личности крутишься. Не надо всех судить по себе, у меня нет мании величия и её не надо тешить танцами вокруг моей персоны. Про синглтоны пожалуйста, про синглтоны...
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[8]: Почему Singleton антипаттерн
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 09:22
    Оценка:
    Здравствуйте, Константин Л., Вы писали:

    КЛ>>>Ну, знаешь, увольте...

    IB>>Хорошо, свободен..
    КЛ>спасибо, можно идти?

    Вон из класса, о недостойный! Ты не признал учения охотников за синглтонами и будешь не просто отлучён от великого гуру, но и навеки проклят вместе со всеми своими потомками! Тысячи лет кровью смывая свою ошибку заслуживать прощения будешь.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[17]: Singleton действительно антипаттерн в enterprize при
    От: AndrewJD США  
    Дата: 13.08.07 09:42
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я уже привёл решение не требующее переписывания клиентов.

    A>http://www.rsdn.ru/Forum/Message.aspx?mid=2618283&amp;only=1
    Автор: adontz
    Дата: 12.08.07


    Не совсем понял, что ты конкретно предлагаешь: на каждом уровне добавлять/удалять логгеры или чтобы фильтры сами разбирались какое сообщение куда они пишут и должны ли они передовать вызов дальше по цепочке фильтров?
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[21]: Singleton действительно антипаттерн в enterprize при
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 11:06
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я не понял твой мысли о явности, приведи пример языка и кода.

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

    A>Я с этим мнением не согласен

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

    A>В том что синглтон при правильном использовании не причиняет проблем

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

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

    К сожалению получается наоборот — твоя моральная неустойчивость становится проблемой окружающих.

    A>Верно.

    Твои проблемы..

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

    "The term factory method is often used to refer to any method whose main purpose is creation of objects"
    Это объективная реальность. Ты можешь с этим не соглашаться, но тогда у тебя будут постоянные терминологические проблемы.
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Мы уже победили, просто это еще не так заметно...
    Re[10]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 11:06
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я теперь играю в игру "кто не смог остановиться".

    У тебя хорошо получается..

    A>Опять личный наезд?

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

    A>Про синглтоны пожалуйста, про синглтоны...

    Я тебе уже все про них рассказал, если не понимаешь — извеняй.
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Мы уже победили, просто это еще не так заметно...
    Re[19]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 13.08.07 11:25
    Оценка:
    Здравствуйте, adontz, Вы писали:

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

    A>Можно.
    Это мягко говоря не то.
    Мне не нужно выводить в несколько логгеров. Хотя эсли это понадобится я это легко сделаю.
    Логгер у меня один но много сессий. И для каждой сесии нужно что-то дописать в лог.
    А внутри сессии есть запросы. И для каждого запроса тоже что-то нужно дописать в лог.
    Таким образом из лога в который в много потоков пишут кучу всякой дряни можно банальным grep'ом выцепить отдельную сессию и каждый отдельный запрос сессии.
    На синглетонах это не делается.

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

    хъ
    A>потому что заставлять клиента явно создавать делегат и хранить на него ссылку не катит.
    A>Таких сюрпризов у меня в своё время было не мало.
    Скрещивание ежа с ужом это разговор отдельный и в любом случае требует изучения работы всех функций.
    Кстати зачем выделеное SomeGlobalDelegateTable? В многопоточностью проблем не боишься?

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

    Не грузить то что грузить не нужно никак не связано с тем используются синглетоны или нет.
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[18]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 12:23
    Оценка:
    Здравствуйте, AndrewJD, Вы писали:

    AJD>Не совсем понял, что ты конкретно предлагаешь: на каждом уровне добавлять/удалять логгеры


    На каждом, конечно же не надо, но Wolfhound захотел иметь возможность подменить (декорировать?) на уровне 2 логгер скончифурированный на уровне 1 и используемый на уровне 3. Эта возможность есть, задача решена.

    AJD>или чтобы фильтры сами разбирались какое сообщение куда они пишут и должны ли они передовать вызов дальше по цепочке фильтров?


    Это уже детали реализации, я привёл лишь один из вариантов. На самом деле message bubbling одно из самых гибких и расширяемых решений, не говоря уже о том, что оно мною очень любимо . Как именно будет реализована передача вызовов по цепочке сильно зависит от задачи.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[20]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 12:39
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>Мне не нужно выводить в несколько логгеров. Хотя эсли это понадобится я это легко сделаю.

    WH>Логгер у меня один но много сессий. И для каждой сесии нужно что-то дописать в лог.
    WH>А внутри сессии есть запросы. И для каждого запроса тоже что-то нужно дописать в лог.

    Chain of Responsibility позволяет декорировать поведение. Ты делаешь базовый логгер и логгер который что-то дописывает в зависимости от сессии, расшряя (но не заменяя) поведение базового. Я не зря указал отдельно is_handled и отдельно is_canceled. Воспринимай Chain of Responsibility как список декораторов (собственно это и есть список декораторов).

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

    WH>Кстати зачем выделеное SomeGlobalDelegateTable? В многопоточностью проблем не боишься?

    Global потому что время жизни подписки может быть больше, чем время жизни объекта. Например, возьмём интероп к HTMLayout.
    Есть HTML код
    <html>
        <head>
        </head>
        <body>
            <div id="box" style="width: 100px; height: 100px">
               Click me!
            </div>
        </body>
    </html>

    и я хочу подписаться на мышиное сообщение для div. Выглядит это так
    HtmlTag div = _htmlView.Root.SelectFirst("div#box");
    div.Mouse += OnMouse;

    После чего объект div благополучно уничтожается и собирается сборщиком мусора, а вот оповещения в OnMouse приходят.

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


    Просто с синглтонами эта проблема решается сама собой, без дополнительных усилий.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[19]: Singleton действительно антипаттерн в enterprize при
    От: AndrewJD США  
    Дата: 13.08.07 13:08
    Оценка:
    Здравствуйте, adontz, Вы писали:

    AJD>>Не совсем понял, что ты конкретно предлагаешь: на каждом уровне добавлять/удалять логгеры

    A>На каждом, конечно же не надо, но Wolfhound захотел иметь возможность подменить (декорировать?) на уровне 2 логгер скончифурированный на уровне 1 и используемый на уровне 3. Эта возможность есть, задача решена.

    В случае многопоточности, прийдется все запихивать в TLS, а иначе будет ой.
    Использование TLS многие проблемы решает, поскольку это контекст поддерживаемый системой. Но отлаживать его вряд ли будет удобно.
    "For every complex problem, there is a solution that is simple, neat,
    and wrong."
    Re[21]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 13.08.07 14:51
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Chain of Responsibility позволяет декорировать поведение. Ты делаешь базовый логгер и логгер который что-то дописывает в зависимости от сессии, расшряя (но не заменяя) поведение базового. Я не зря указал отдельно is_handled и отдельно is_canceled. Воспринимай Chain of Responsibility как список декораторов (собственно это и есть список декораторов).

    И как мне поможет цепочка? Мне нужно дерево. Есть один логгер который пишет в файлик. Есть сотня активных сессий. У каждой сесии куча запросов. При помощи DI я это делаю легко. Как это сделать синглетонами не ясно.
    Передавать при каждом вызове логгера информацию о сессии и запросе не вариант.

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

    A>Есть HTML код
    хъ
    A>После чего объект div благополучно уничтожается и собирается сборщиком мусора, а вот оповещения в OnMouse приходят.
    Оповещения для мертвого объекта?! Ахринеть! ИМХО либо ты либо c-smile гдето накосячили.

    A>Просто с синглтонами эта проблема решается сама собой, без дополнительных усилий.

    синглетоны сами по себе одни сплошные дополнительные усилия.
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[5]: Почему Singleton антипаттерн
    От: Igor Trofimov  
    Дата: 13.08.07 16:18
    Оценка:
    iT>>И плюсы/минусы этих зависимостей остаются теми же.
    IT>Плюсы/минусы остаются. Разница в том, что количество проблемных мест с этими плюсами/минусами резко сокращается, а в большинстве случаев стремится к нулю.

    Да ладно уж — резко... что реализацию статического свойства подкрутиить, возможно даже заменив тип реально возвращаемого экземпляра, то ли в конфиге то же поправить — один фиг.
    Re[6]: Почему Singleton антипаттерн
    От: IT Россия linq2db.com
    Дата: 13.08.07 17:25
    Оценка:
    Здравствуйте, Igor Trofimov, Вы писали:

    iT>Да ладно уж — резко... что реализацию статического свойства подкрутиить, возможно даже заменив тип реально возвращаемого экземпляра, то ли в конфиге то же поправить — один фиг.


    Проблемы не с самим синглетоном, проблемы с кодом, который его использует. И вообще, ты синглетон с фабрикой случайно не путаешь?
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[22]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 18:05
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    WH>И как мне поможет цепочка? Мне нужно дерево. Есть один логгер который пишет в файлик. Есть сотня активных сессий. У каждой сесии куча запросов. При помощи DI я это делаю легко. Как это сделать синглетонами не ясно.

    WH>Передавать при каждом вызове логгера информацию о сессии и запросе не вариант.

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

    WH>Оповещения для мертвого объекта?!


    Нет, OnMouse метод формы. Форма жива, куда она денется?
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[3]: Почему Singleton антипаттерн
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 18:11
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    Игорь, а причём тут синглтоны? Если ты попытаешься вынести с сервера на клиент любой код который завязан на что-то, чему на клиенте делать нечего, будут проблемы. Ты понимаешь в чём дело, я не фанат синглтонов, но вы всё время приводите какие-то левые недостатки непосредственно к синглтонам отношения не имеющие. Неубедительно.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[22]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 18:19
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    A>>После чего объект div благополучно уничтожается и собирается сборщиком мусора, а вот оповещения в OnMouse приходят.

    WH>Оповещения для мертвого объекта?! Ахринеть! ИМХО либо ты либо c-smile гдето накосячили.

    Вобщем вот как оно выглядит. Выздал из примера.
            public MainForm()
            {
                InitializeComponent();
            }
    
            private void MainForm_Load(object sender, EventArgs e)
            {
                // Подписались.
                // Временные объекты HtmlTag которые вернули вызовы this._htmlView.Root.SelectFirst сдохли.
                this._htmlView.Root.SelectFirst("#add_row").Behavior += new HtmlBehaviorEventHandler(AddRow_OnMouse);
                this._htmlView.Root.SelectFirst("#remove_row").Behavior += new HtmlBehaviorEventHandler(RemoveRow_OnMouse);
            }
    
            public bool AddRow_OnMouse(
                IntPtr forInternalUse,
                IntPtr hTag,
                HtmlEventGroup eventGroup,
                ref HtmlBehaviorEventParameters parameters)
            {
                // While this application is an example, it can be used as test of event dispatching system.
                // The following lines make you sure that Nabu.Forms.HtmlLayout keeps
                // managed references to delegates internally not allowing them to be collected.
                GC.Collect();
                GC.WaitForPendingFinalizers();
    
                return false;
            }
    
            public bool RemoveRow_OnMouse(
                IntPtr forInternalUse,
                IntPtr hTag,
                HtmlEventGroup eventGroup,
                ref HtmlBehaviorEventParameters parameters)
            {
                // While this application is an example, it can be used as test of event dispatching system.
                // The following lines make you sure that Nabu.Forms.HtmlLayout keeps
                // managed references to delegates internally not allowing them to be collected.
                GC.Collect();
                GC.WaitForPendingFinalizers();
    
                return false;
            }
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[3]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 19:19
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT> А учитывая, что серьёзных архитектурных преимуществ синглетон не даёт, то гораздо проще и разумнее предать его анафеме и не связываться с ним даже в тех случаях, когда с ним проблем не возникает.

    "Устав написан кровью" (с)
    =)
    Мы уже победили, просто это еще не так заметно...
    Re[2]: Почему Singleton антипаттерн
    От: IB Австрия http://rsdn.ru
    Дата: 13.08.07 19:26
    Оценка:
    Здравствуйте, Ужасть бухгалтера, Вы писали:

    УБ>"Вторая главная проблема синглтона в том, что это первый описанный антипаттерн".

    Ну, не первый... Но можно сказать — классический..

    УБ>То сейчас на встреченный синглтон: "Вы чё, чуваки, офигели? Вы шо, не знаете, шо синглтон — АНТИПАТТЕРН, ёптыть?!" Говорящий выглядит еще более крутым и умным, ибо читает, оказывается, еще более умные и модные книжки. При этом заодно повышает свою самооценку, т.к. получает возможность возвыситься над ретроградами, ничтожными юзерами синглтонов.

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

    УБ> А то из-за ожесточенного флейма в этой ветке возникает впечатление, что некоторые зачем-то пытаются свести использование синглтона вообще к нулю.

    Ой не говори. Не флеймили бы по пустякам, да еще бы внимательно читали, с чем спорят — вообще рай был бы...
    Мы уже победили, просто это еще не так заметно...
    Re[23]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 13.08.07 20:11
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я что-то совсем не понял зачем тебе дерево. Можно примерчик простенький?

    Я уже раз 10 написал.
    Ладно еще раз:
    Запускаем сервер.
    Создаем логгер.
    Подключаются несколько пользователей. Для каждого создается сессия.
    Для каждой сессии при выводе в лог нужно добавить некий UID сессии.
    Сесии обрабатываются паралельно.

    A>Нет, OnMouse метод формы. Форма жива, куда она денется?

    Вот пусть форма и отдувается. Причем тут div?
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[21]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 13.08.07 20:13
    Оценка:
    Здравствуйте, adontz, Вы писали:

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


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


    Я же тебе привёл пример, где ничего переписывать не надо.
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[24]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 20:34
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    A>>Нет, OnMouse метод формы. Форма жива, куда она денется?

    WH>Вот пусть форма и отдувается. Причем тут div?

    Так события-то относятся к div. Это его managed обёртка создаётся и уничтожается, а сам div живёт.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[22]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 13.08.07 20:40
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    IT>Я же тебе привёл пример, где ничего переписывать не надо.


    С уровнями? Где?!
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[23]: Singleton действительно антипаттерн в enterprize при
    От: IT Россия linq2db.com
    Дата: 14.08.07 01:51
    Оценка:
    Здравствуйте, adontz, Вы писали:

    IT>>Я же тебе привёл пример, где ничего переписывать не надо.


    A>С уровнями? Где?!


    Re[13]: Singleton действительно антипаттерн в enterprize при
    Автор: IT
    Дата: 12.08.07
    ... << RSDN@Home 1.2.0 alpha rev. 0>>
    Если нам не помогут, то мы тоже никого не пощадим.
    Re[25]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 14.08.07 07:54
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Я просто не очень понимаю, какая разница что таскать за собой: специфический логгер или идентификатор сессии.

    А я не логгер таскаю. Я таскаю ServiceProvider или болие специализированный объект реализующий этот интерфейс.
    А его по любому таскать нужно ибо там еще куча всякой всячины лежит.

    A>То есть в чём твоя глобальная выгода? В том что ты не указываешь id явно?

    А зачем логгеру знать о сессиях? А еще есть запросы. А там еще чтонибудь появится...
    Причем наличие того или ного объекта зависит от того в какой стадии находится программа...
    Итого: В моем случае куча независимых кирпичиков которые можно добаввлять, удалять, комбинировать..., а в твоем монолит в котором все знает про все.
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[25]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 14.08.07 07:54
    Оценка:
    Здравствуйте, adontz, Вы писали:

    WH>>Вот пусть форма и отдувается. Причем тут div?

    A>Так события-то относятся к div. Это его managed обёртка создаётся и уничтожается, а сам div живёт.
    Кошмар! Точно кто-то сильно накосячил.
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[27]: Singleton действительно антипаттерн в enterprize при
    От: WolfHound  
    Дата: 14.08.07 09:24
    Оценка:
    Здравствуйте, adontz, Вы писали:

    A>Да нет, всё нормально. просто ты пока, наверное, не вкурил...

    Куда уж мне...
    ... << RSDN@Home 1.2.0 alpha rev. 673>>
    Пусть это будет просто:
    просто, как только можно,
    но не проще.
    (C) А. Эйнштейн
    Re[28]: Singleton действительно антипаттерн в enterprize при
    От: adontz Грузия http://adontz.wordpress.com/
    Дата: 14.08.07 10:09
    Оценка:
    Здравствуйте, WolfHound, Вы писали:

    A>>Да нет, всё нормально. просто ты пока, наверное, не вкурил...

    WH>Куда уж мне...

    Этой библиотекой пользуюсь далеко не только я. Никто из тех, кто реально пользуется и разбирается в предметной области не жаловался. Мне искрене жаль, что я разочаровал дизайном великого тебя.
    A journey of a thousand miles must begin with a single step © Lau Tsu
    Re[7]: Singleton действительно антипаттерн в enterprize прил
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 14.08.07 14:19
    Оценка:
    Здравствуйте, IT, Вы писали:

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


    А они возникают регулярно?

    IT>Хороший паттерн должен быть дуракоустойчив.


    Я лично не знаю ни одного паттерна без побочных эффектов.
    ... << RSDN@Home 1.2.0 alpha rev. 716>>
    AVK Blog
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.