Возможный дубликат:
Что плохого в синглтонах?
Недавно я слышал, что Singleton - это анти-шаблон. Я знаю, что это связано с тем, что класс singleton похож на то, что этот уникальный экземпляр является глобальной переменной, но он также делает намного больше, чем это (ограничение количества экземпляров этого объекта, управление экземпляром и т.д.).
Почему именно Синглтон считается анти-шаблоном? И каковы альтернативы?
Чтобы помочь с ответом, подробнее про комментарий против шаблона:
он злоупотребляет, вводит ненужные ограничения в ситуациях где единственный экземпляр класса фактически не требуется, и вводит глобальное состояние в приложение
От: http://en.wikipedia.org/wiki/Singleton_pattern
Подробнее об этом вы можете узнать: https://www.michaelsafyan.com/tech/design/patterns/singleton
Вот отличный конец в блоге выше:
Короче говоря, одноэлементный шаблон делает код более сложным, менее полезным, и настоящая боль для повторного использования или тестирования. Исключение синглтонов может быть но это достойная работа.
ОК, поэтому причина этого анти-шаблона хорошо описана в этом параграфе, и, как автор выражает, он плотно связывает ваш код с синглом.
Если вы обнаружите, что хотите использовать синглтон, вы можете рассмотреть свой дизайн, но есть моменты, когда это полезно.
Например, когда я должен был написать приложение, которое может иметь не более одного соединения с базой данных, обрабатывать тысячи запросов. Итак, одноэлемент имеет смысл, так как я ограничен ресурсами, имея только один экземпляр.
Но, как правило, это используется для упрощения кода, не задумываясь о трудностях, которые будут введены.
Например, это относится и к статическим классам, если вы unit test или имеете concurrency, тогда состояние одного запроса изменит состояние и может вызвать проблемы, поскольку класс, вызывающий экземпляр, может быть предполагая, что состояние такое, как ожидалось.
Я думаю, что лучший способ бросить вызов использованию - подумать о том, как обращаться с ним, если ваша программа многопоточная, и простой способ сделать это - это unit test, если у вас есть несколько тестов, которые выполняются на один раз.
Если вы обнаружите, что вам все еще нужно, используйте его, но поймите, какие проблемы возникнут позже.
Я бы точно не рассматривал singleton как анти-шаблон.
Однако singleton - это в основном способ использования глобальных переменных. И глобальные переменные плохи, потому что любой код в любой точке системы может изменять свои значения. Поэтому при отладке может быть сложно определить, какой путь кода ведет к текущему состоянию singleton.
Я думаю, что это считается анти-шаблоном, потому что класс Singleton не может быть создан обычным способом другим объектом (за исключением вызова такого метода, обычно называемого "getInstance" ). Таким образом, он будет выглядеть так, как будто класс используется напрямую, не создавая его, чтобы сначала создать полезный объект.
Я согласен с вами в том, что Singleton может служить глобальным уникальным экземпляром. Я узнал от некоторых людей, что в качестве альтернативы для Singleton мы можем использовать статические и/или конечные переменные, и мы также можем использовать перечисление (чтобы мы могли группировать несколько переменных под одним именем группы как обычно, когда мы работаем с использованием нормальный класс/объект).
Однако эти альтернативы могут только соответствовать возможности класса Singleton при сохранении состояний/значений. Если нам нужны уникальные функции для работы, эти статические/конечные переменные и перечисления не могут помочь. На мой взгляд, это тот случай, когда нам нужно использовать класс Singleton (когда нам нужны некоторые уникальные функции для работы со статическими/конечными состояниями/значениями).
Приветствия::))
Синглеты часто плохо реализуются. См. Блокировка с двойной проверкой.
В какой области видимости должен быть экземпляр Singleton уникальным. Как многопоточные среды, кластеризация и т.д.
Синглеты могут быть трудными для тестирования.
Память, выделенная для Singleton, не может быть освобождена.
С избыточным использованием синглтонов вы выходите из объектно-ориентированного программирования в процедурное программирование.