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

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

M>>>Например пул потоков. Очевидно что для эфективности такой объект должен жить в одном экземпляре.

V>>Жить в одном экземпляре и синглтон — это не одно и тоже.

M>Конечно это разные вещи. А вот жить гарантированно в одном экземпляре — это одно и то-же.


V>>Обычно под синглтоном понимают конкретную его реализацию (я имею ввиду со статическим методом).

M>То есть ты себе что-то понимаешь, и с этим чем-то споришь.

V>>Чем это лучше варианта, когда доступ к объекту получаем не через статический метод класса, а через обычный метод обычного объекта?

M>Тем, что есть вещи семантически уникальные. Как только их становится несколько — это нарушение контракта и дизайна.
M>Чаще всего таких объектов вообще не надо иметь (в смысле — не обязательно их иметь). Раз он один, уникальный, то и не нужен он.
M>Единственный существующий пул тредов можно заменить набором статических методов и переменных.
M>List.Nil можно заменить чем-то вроде нулевого указателя и т.д.
M>А шаблон singleton применяют в случаях, когда дизайн (приложения, библиотеки, метода) требует объекта, инстанса — просто
M>нужно передать ссылку на объект. Т.е. ограничение языка программирования, его средств. Шаблонные решения потом, зачастую,
M>входят в сам язык программирования. Скажем, singleton вошёл в Scala как object (в отличие от их class-а).
M>Вошёл именно потому, что это действительно самантическая и удобная абстракция, а не какой-то buzz-word.

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

Во-вторых, при использовании синглтона делается излишне смелое предположение, что объект обязан быть уникальным во всем мире, в любых условиях и любых вариантах использования. Это черевато граблями. Правильнее вообще не делать предположений об уникальности объекта (99%), а если и делать, то только в _рамках_ некоторого ограниченного контекста (1%).