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

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

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

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

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

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

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

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

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