Почему Singleton антипаттерн - Архитектура программного обеспечения

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

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

[]

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

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

[]

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

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

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

GetService(typeof(MyService))

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

Singleton<MyService>.Instance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ISomeClass
{
    void Do( IServiceProvider )

    or

    void Do( Ilogger )
}

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

ISomeClass
{
    void Do()
}

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

[]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

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

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

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

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

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

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

Having no information about what occurred previously.

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

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

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

Having no information about what occurred previously.

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

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

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

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

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

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

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

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	От:	Константин Л.
	Дата:	11.08.07 13:23
	Оценка:

	От:	Cyberax
	Дата:	11.08.07 13:27
	Оценка:

	От:	Константин Л.
	Дата:	11.08.07 13:31
	Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	11.08.07 13:55
Оценка:

	От:	Cyberax
	Дата:	11.08.07 14:00
	Оценка:

От:	IT	linq2db.com
Дата:	11.08.07 15:13
Оценка:	+1

	От:	Igor Trofimov
	Дата:	11.08.07 17:10
	Оценка:	+1