Здравствуйте, 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