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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GetService(typeof(MyService))

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

Singleton<MyService>.Instance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    res.send( command );
}

typedef Singleton< SomeResource > Device;

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

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

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

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

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

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

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

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

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