Если бы синглтон был плохим способом обеспечения единственности экземпляра, то он бы не был паттерном для решения задачи по обеспечению единственности экземпляра класса.
1) Увеличение связности кода. В местах вызова жестко задается имя класса.
Связанность кода присутствует всегда. Среднестатистический контроллер делает несколько инстансов разных объектов - это тоже связанность кода. Жестко заданное имя класса - что в этом такого страшного?
это так важно?
Да в общем то ничего, но я не сторонник методики использования имени класса в каждой точке, где нужен объект, а не класс. Это совсем не значит, что я не использую синглтоны, но стараюсь строить такие архитектуры где они будут применяться реже.
Да. Особенно это становится важно, когда объект синглтона уже уничтожен, а из какого-либо деструктора другого класса запрашивается этот объект. Счастливая отладка гарантирована. По этому и глобальные переменные тоже зло. (Я говорил про С++, так как последнее время все больше пишу на нем).
Это не форум по С++, давайте перестанем придумывать граничные условия из головы, после которых сказанная глупость якобы имеет право на существование? Давай еще скажем, что в паскале статических классов нет, поэтому синглтоны там работать не будут, и поэтому они плохая практика.
кстати очень правильное замечание про Паскаль, считаю что в пхп по этой причине нельзя использовать синглтоны!
Количество синглтонов надо сводить к минимуму, либо избавляться от его минусов. Не потому что это "дурной тон", а потому, что это статическая зависимость на класс. Введение метода setInstance() позволяет отвязаться от класса и перейти к интерфейсу.
Неее, ты путаешь. Синглтон не "правоцирует нарушения", он является "нарушением". Без setInstance() (который можно при необходимости добавить, и запихнуть инстанцирование в bootstrap) он увеличивает стоимость вносимых изменений.
Минусы этого подхода описать не хотите?
