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

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

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

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

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

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

IB>4. Наличие синглтона понижает тестируемость приложения в целом и классов, которые используют синглтон, в частности. Во-первых, вместо синглтона нельзя подпихнуть Mock-объект, а во-вторых, если синглтон имеет интерфейс для изменения своего состояния, то тесты начинают зависеть друг от друга.

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

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