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

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

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

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

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

IB>Естественно, можно акккуратненько пройти по граблям и использовать синглетон, но (цитата из доки к пикоконтейнеру) "Overuse makes for bad solutions. At the enterprise level, it makes for very very bad solutions"...
Ну так там сказано четко overuse, а не use.