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