Что такого плохого в синглетах? [закрыто]

Проблемы с синглетонами - это проблема увеличенного объема и, следовательно, связи . Нельзя отрицать, что в некоторых ситуациях вам нужен доступ к одному экземпляру, и это может быть достигнуто другими способами.

Теперь я предпочитаю проектировать контейнер с инверсией управления (IoC) и разрешать контейнером управлять временем жизни. Это дает вам преимущество того, что классы, зависящие от экземпляра, не знают о том, что существует один экземпляр. Время жизни синглтона может быть изменено в будущем. Однажды с таким примером, с которым я недавно столкнулся, была простая настройка от однопоточного к многопоточному.

FWIW, если это PIA, когда вы пытаетесь выполнить его модульное тестирование, то он отправляется в PIA, когда вы пытаетесь отладить, исправить ошибку или улучшить ее.

Недавняя статья на эту тему Криса Рита в Кодирование без комментариев .

Примечание. Кодирование без комментариев больше не действует. Тем не менее, ссылка на статью была клонирована другим пользователем.

http://geekswithblogs.net/AngelEyes/archive/2013/09/08/singleton-i-love-you-but-youre-bringing-me-down-re-uploaded.aspx

Во-первых, класс и его сотрудники должны, во-первых, выполнять свое предназначение, а не фокусироваться на учениках. Управление жизненным циклом (когда экземпляры создаются и выходят за рамки) не должно входить в сферу ответственности cladses. Для этого рекомендуется создать или настроить новый компонент для управления зависимостями с помощью внедрения зависимостей.

Часто программное обеспечение усложняется, имеет смысл иметь несколько независимых экземпляров класса «singleton» с различным состоянием. В таких случаях использование кода для простого захвата синглтона является неправильным. Использование Singleton.getInstance () может подойти для небольших простых систем, но оно не работает / не масштабируется, когда может потребоваться другой экземпляр того же класса.

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

Проблемы, которые одноэлементные вызывают в тестировании, являются признаком их жестко запрограммированного варианта использования / среды. Набор тестов и множество тестов являются отдельными и отдельными, что несовместимо с жестким программированием одиночного кода.

Синглтоны не являются злом, если вы правильно их используете & amp; минимально . Существует множество других хороших шаблонов проектирования, которые в какой-то момент заменяют потребности в синглтоне (& также дают лучшие результаты). Но некоторые программисты не знают об этих хороших шаблонах & amp; использует синглтон для всех случаев, что делает синглтон злом для них.

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

Плохая часть синглтона - это, как правило, пользователь (или я должен сказать, нецелевое использование синглтона для вещей, для которых он не предназначен). Крупнейший преступник использует синглтон в качестве фальшивой глобальной переменной.

Синглтоны плохи с точки зрения пуриста.

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

Если вы знаете, что ваше приложение не изменится настолько, с ним все в порядке. Просто знайте, что вам может потребоваться рефакторинг, если ваши требования неожиданно изменятся (что в большинстве случаев вполне нормально).

Синглтоны иногда также усложняют юнит-тестирование .

Слишком много людей помещают объекты, которые не являются потокобезопасными, в шаблон синглтона. Я видел примеры DataContext ( LINQ & to nbsp; SQL ), выполненного в одноэлементном шаблоне, несмотря на тот факт, что DataContext не является потокобезопасным и является чисто единичным объектом.

Я хотел бы остановиться на 4 пунктах в принятом ответе, надеюсь, кто-то может объяснить, почему я не прав.

1. Почему сокрытие зависимостей в вашем коде плохо? Уже есть десятки скрытых зависимостей (вызовы времени выполнения C, вызовы API OS, вызовы глобальных функций), и одноэлементные зависимости легко найти (поиск instance ()).

   «Создание чего-то глобального, чтобы избежать его распространения, является запахом кода». Почему бы не передать что-то, чтобы не сделать это одним запахом кода?

   Если вы пропускаете объект через 10 функций в стеке вызовов только для того, чтобы избежать одиночного перехода, это так здорово?

2. Принцип единой ответственности: я думаю, что это немного расплывчато и зависит от вашего определения ответственности. Уместным будет вопрос: почему добавление этой конкретной «ответственности» к классу имеет значение?

3. Почему передача объекта в класс делает его более тесно связанным чем использовать этот объект в качестве синглтона из класса?

4. Почему он меняется, как долго длится состояние? Синглтоны могут быть созданы или уничтожены вручную, поэтому элемент управления все еще там, и вы можете сделать время жизни таким же, как было бы время жизни не-одиночного объекта.

Относительно юнит-тестов:

• не все классы должны быть юнит-тестами
• не все классы, которые должны быть юнит-тестами, должны изменить реализацию синглтона
• если они действительно нуждаются в модульном тестировании и действительно нуждаются в изменении реализации, легко изменить класс с использования синглтона на передачу синглтона ему посредством внедрения зависимостей.

Вот еще одна вещь о синглетах, о которой еще никто не говорил.

В большинстве случаев «синглтонность» - это деталь реализации некоторого класса, а не характеристика его интерфейса. Обращение Контейнер Контроля может скрыть эту характеристику от пользователей класса; вам просто нужно пометить ваш класс как одиночный (например, с аннотацией @Singleton в Java) и все; IoCC сделает все остальное. Вам не нужно предоставлять глобальный доступ к вашему экземпляру синглтона, потому что доступ уже управляется IoCC. Таким образом, нет ничего плохого в IoC Singletons.

Предполагается, что GoF Singletons в отличие от IoC Singletons предоставляют «единство» в интерфейсе с помощью метода getInstance (), и поэтому они страдают от всего, что сказано выше.

Мой ответ о том, как синглтоны плохие, всегда таков: «их трудно сделать правильно». Многие из основополагающих компонентов языков являются синглетонами (классы, функции, пространства имен и даже операторы), как и компоненты в других аспектах вычислений (localhost, маршрут по умолчанию, виртуальная файловая система и т. Д.), И это не случайно. Хотя они время от времени доставляют неприятности и разочарование, они также могут заставить многое работать намного лучше.

Два самых больших провала, которые я вижу: это отношение к глобальному & amp; не в состоянии определить замыкание Синглтона.

Все говорят о Синглтоне как о глобале, потому что в основном это так. Тем не менее, большая (к сожалению, не вся) вредность в глобальном масштабе проистекает не из того, что он глобальный, а из-за его использования. То же самое касается синглетонов. На самом деле тем более, что «единый экземпляр» действительно не обязательно означает «глобально доступный». Это более естественный побочный продукт, и, учитывая все плохое, что мы знаем, оно исходит от нас, мы не должны спешить использовать глобальную доступность. Как только программисты видят Singleton, они, кажется, всегда получают к нему доступ напрямую через метод его экземпляра. Вместо этого вы должны перейти к нему так же, как к любому другому объекту. Большая часть кода даже не должна знать, что имеет дело с синглтоном (слабая связь, верно?). Если только небольшой кусочек кода обращается к объекту, как к глобальному объекту, большой вред отменяется. Я рекомендую применять его, ограничивая доступ к функции экземпляра.

Контекст Singleton также очень важен. Определяющей характеристикой Singleton является то, что существует «только один», но на самом деле он «только один» в некотором контексте / пространстве имен. Обычно это один из них: один на поток, процесс, IP-адрес или кластер, но также может быть один на процессор, компьютер, пространство имен языка / загрузчик классов / что угодно, подсеть, Интернет и т. Д.

Другая, менее распространенная ошибка - игнорировать образ жизни Синглтона. Тот факт, что существует только один, не означает, что синглтон является всемогущим «всегда был и всегда будет», и это не всегда желательно (объекты без начала и конца нарушают все виды полезных допущений в коде и должны использоваться только в самых безвыходных обстоятельствах.

Если вы избежите этих ошибок, Singletons все еще могут быть PITA, хотя он готов увидеть, что многие худшие проблемы значительно смягчены. Представьте себе Java Singleton, который явно определяется как один раз для загрузчика классов (что означает, что ему нужна политика безопасности потоков), с определенными методами создания и уничтожения и жизненным циклом, который определяет, когда и как они вызываются, и чей «экземплярный» метод имеет защиту пакетов, поэтому к нему обычно обращаются через другие, не глобальные объекты. Все еще потенциальный источник проблем, но, конечно, намного меньше проблем.

К сожалению, вместо того, чтобы преподавать хорошие примеры того, как делать Singletons. Мы преподаем плохие примеры, позволяем программистам убегать, используя их на время е, а затем скажите им, что они плохой шаблон проектирования.

Синглтон реализуется статическим методом. Люди, которые проводят модульное тестирование, избегают статических методов, потому что их нельзя высмеять или зарезать. Большинство людей на этом сайте являются большими сторонниками модульного тестирования. Общепринятым соглашением об их избежании является использование паттерна инверсии управления .

Синглтон & ndash; анти-паттерн! Марка Рэдфорда (Overload Journal № 57 - октябрь 2003 г.) - хорошее прочтение о том, почему Синглтон считается анти-паттерном. В статье также обсуждаются два подхода к разработке альтернатив для замены синглтона.

Это размывает разделение интересов .

Предположим, что у вас есть синглтон, вы можете вызвать этот экземпляр из любой точки вашего класса. Ваш класс уже не так чист, как должно быть. Ваш класс больше не будет воздействовать на своих членов и членов, которые он получает явно. Это создаст путаницу, потому что пользователи класса не знают, какая информация необходима классу. Вся идея инкапсуляции состоит в том, чтобы скрыть метод метода от пользователей, но если внутри метода используется синглтон, то для правильного использования метода необходимо знать его состояние. , Это анти- ООП .

Синглтон-паттерн сам по себе не является проблемой. Проблема заключается в том, что шаблон часто используется людьми, разрабатывающими программное обеспечение с объектно-ориентированными инструментами, не имея четкого понимания концепций ОО. Когда синглтоны вводятся в этом контексте, они имеют тенденцию превращаться в неуправляемые классы, которые содержат вспомогательные методы для каждого небольшого использования.

Синглтоны также являются проблемой с точки зрения тестирования. Они, как правило, затрудняют написание отдельных юнит-тестов. Инверсия управления (IoC) и внедрение зависимостей - это паттерны, предназначенные для решения этой проблемы объектно-ориентированным образом, который поддается модульное тестирование.

В сборщике мусора среда одиночных игр может быстро стать проблемой в отношении управления памятью.

Существует также многопоточный сценарий, когда синглтоны могут стать узким местом, а также проблемой синхронизации.

Миско Хевери, из Google, имеет несколько интересных статей именно на эту тему ...

Синглтоны - это патологические лжецы. содержит пример модульного тестирования, который иллюстрирует, как синглтоны могут затруднить определение цепочек зависимостей и запуск или тестирование приложения. Это довольно экстремальный пример жестокого обращения, но высказанное им мнение остается в силе:

Синглтоны - не более чем глобальное состояние. Благодаря глобальному состоянию ваши объекты могут тайно овладевать вещами, которые не объявлены в их API, и, в результате, Singletons превращают ваши API в патологических лжецов.

Где все ушедшие синглтоны указывают на то, что внедрение зависимостей облегчает получение экземпляров для конструкторов, которые в них нуждаются, что устраняет основную потребность в плохих, глобальных синглетонах, осужденных в первая статья.

Одна довольно плохая вещь в синглетах - это то, что вы не можете расширить их очень легко. По сути, вам нужно встроить какой-нибудь шаблон декоратора или что-то подобное, если вы хотите изменить их поведение. Кроме того, если в один прекрасный день вы захотите иметь несколько способов сделать это, изменение может оказаться довольно болезненным, в зависимости от того, как вы выложили свой код.

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

Таким образом, в основном:

public MyConstructor(Singleton singleton) {
    this.singleton = singleton;
}

, а не:

public MyConstructor() {
    this.singleton = Singleton.getInstance();
}

Я считаю, что этот тип паттерна называется внедрение зависимости и обычно считается хорошей вещью .

Как и любой шаблон, хотя ... Подумайте об этом и подумайте, является ли его использование в данной ситуации неуместным или нет ... Правила обычно нарушаются, и шаблоны не должны применяться произвольно без мыслей.

Я не собираюсь комментировать аргумент добра / зла, но я не использовал их с тех пор, как появилась Spring . Использование внедрения зависимостей в значительной степени сняло мои требования к синглтону, сервис-локаторам и фабрикам. Я считаю, что это намного более продуктивная и чистая среда, по крайней мере, для того типа работы, которую я выполняю (веб-приложения на основе Java).

Синглтоны решают одну (и только одну) проблему.

Ресурсный конфликт.

Если у вас есть какой-то ресурс, который

( 1 ) может иметь только один экземпляр, и

( 2 ) вам нужно управлять этим единственным экземпляром,

вам нужен синглтон .

Примеров не так много. Файл журнала большой. Вы не хотите просто отказаться от одного файла журнала. Вы хотите очистить, синхронизировать и закрыть его правильно. Это пример единого общего ресурса, которым нужно управлять.

Редко нужен синглтон. Причина, по которой они плохие, заключается в том, что они чувствуют себя глобальными , и они полностью оплачены членом книги GoF Design Patterns .

Когда вы думаете, что вам нужна глобальность, вы, вероятно, совершаете ужасную ошибку в дизайне.

Это то, что, по-моему, отсутствует в ответах:

Если вам нужен один экземпляр этого объекта на адресное пространство процесса (и вы настолько уверены, насколько это возможно, что это требование не изменится) ), вы должны сделать его синглтоном.

В противном случае, это не синглтон.

Это очень странное требование, вряд ли когда-либо интересующее пользователя. Процессы и изоляция адресного пространства являются деталями реализации. Они влияют на пользователя только тогда, когда они хотят остановить ваше приложение, используя kill или диспетчер задач.

Помимо построения системы кеширования, не так уж много причин, почему вы были бы настолько уверены, что в каждом процессе должно быть только что-то одно. Как насчет системы регистрации? Может быть, лучше, чтобы это было для каждого потока или более детальным, чтобы вы могли отслеживать происхождение сообщений более автоматически. Как насчет главного окна приложения? Это зависит; возможно, вы захотите, чтобы все документы пользователя по какой-то причине управлялись одним и тем же процессом, и в этом случае в этом процессе будет несколько «главных окон».

Некоторые сноб-кодеры смотрят на них свысока как на прославленную глобализацию. Точно так же, как многие люди ненавидят утверждение goto , есть и другие, которые ненавидят идею когда-либо использовать глобальный . Я видел, как несколько разработчиков пошли на экстраординарную работу, чтобы избежать глобального , потому что они рассматривали возможность использования одного из них как допущение неудачи. Странно, но это правда.

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

У Винса Хьюстона есть эти критерии, которые кажутся мне разумными:

Синглтон следует рассматривать, только если удовлетворены все три из следующих критериев:

• Право собственности на один экземпляр не может быть разумно назначено.
• Ленивая инициализация желательна.
• Глобальный доступ не предусмотрен для

. Например, когда и как происходит инициализация, и глобальный доступ не является проблемой, Синглтон не достаточно интересен.

Дело не в том, что сами синглеты плохие, а в шаблоне GoF. Единственным действительным аргументом, который является действительным, является то, что шаблон проектирования GoF не подходит для тестирования, особенно если тесты выполняются параллельно.

Использование одного экземпляра класса является допустимой конструкцией, если в коде применяются следующие средства:

1. Убедитесь, что класс, который будет использоваться в качестве одиночного, реализует интерфейс. Это позволяет реализовать заглушки или макеты с использованием одного и того же интерфейса

2. Убедитесь, что Singleton является поточно-ориентированным. Это данность.

3. Синглтон должен быть простым по своей природе и не слишком сложным.

4. Во время выполнения приложения, в котором необходимо передать синглеты данному объекту, используйте фабрику классов, которая создает этот объект, и фабрика классов передает экземпляр синглтона нужному классу.

5. Во время тестирования и для обеспечения детерминированного поведения создайте одноэлементный класс в качестве отдельного экземпляра в качестве самого фактического класса или заглушки / макета, который реализует его поведение, и передайте его как есть классу, который требует его. Не используйте фактор класса, который создает тестируемый объект, который нуждается во синглтоне во время теста, так как он пройдет единственный глобальный экземпляр этого объекта, что противоречит цели.

Мы использовали Singletons в наших решениях с большим успехом, которые можно тестировать, обеспечивая детерминированное поведение в параллельных потоках тестовых прогонов.

Паттерн возникает, когда несколько человек (или команд) приходят к одинаковым или идентичным решениям. Многие люди до сих пор используют синглтоны в их оригинальном виде или с помощью заводских шаблонов (хорошее обсуждение в Modern C ++ Design Александреску). Параллельность и сложность в управлении временем жизни объекта являются главными препятствиями, а первые легко управляются, как вы предлагаете.

Как и все варианты, у Синглтона есть свои плюсы и минусы. Я думаю, что они могут быть использованы в модерации, особенно для объектов, которые выживают в течение срока службы приложения. Тот факт, что они похожи (и, вероятно, являются) глобалами, предположительно вызвал пуристов.

Монополия - это дьявол, а синглтоны с нечитаемым / изменяемым состоянием - это «настоящая» проблема ...

После прочтения синглетоны являются патологическими лжецами , как предложено в ответе Джейсона . Я наткнулся на этот небольшой кусочек, который дает лучший из представленных примеров , как синглтоны часто неправильно используются. .

Глобально это плохо, потому что:

• а. Это вызывает конфликт пространства имен
• b. Это разоблачает состояние необоснованным образом

Когда дело доходит до синглетонов

• a. Явный ОО способ их вызова предотвращает конфликты, поэтому укажите а. не является проблемой
• b. Синглтоны без состояния (как фабрики) не являются проблемой. Синглтоны с состоянием могут снова попасть в две категории, которые являются неизменяемыми или пишутся один раз и читают много (файлы конфигурации / свойств). Это не плохо. Вы можете говорить об изменчивых синглетонах, которые являются своего рода держателями ссылок.

В последнем утверждении он ссылается на концепцию блога «одиночки - лжецы».

Как это относится к монополии?

Чтобы начать игру в монополию, сначала:

• сначала мы устанавливаем правила, чтобы все были на на одной и той же странице
• всем дают равное начало в начале игры
• представлен только один набор правил, чтобы избежать путаницы
• правила не могут изменяться на протяжении всей игры

Теперь для тех, кто не действительно играл в монополию, эти стандарты в лучшем случае идеальны. Трудно проглотить поражение в монополии, потому что монополия - это деньги, если вы проигрываете, вы должны тщательно следить за тем, как остальные игроки заканчивают игру, а потери обычно бывают быстрыми и сокрушительными. Таким образом, правила обычно изменяются в какой-то момент, чтобы служить личным интересам некоторых игроков за счет других.

Теперь игра переходит от дружелюбной игры в кости к серьезному бизнесу. Боб стал примером неудачи, а Джо и Эд не хотят в конечном итоге стать «тем парнем». Итак, будучи ведущим игроком, вы внезапно становитесь врагом. Джо и Эд начинают практиковать сделки «за столом», денежные вливания за спиной, недооцененный обмен домами и вообще все, что может ослабить вас как игрока, пока один из них не поднимется на вершину.

Затем, вместо того, чтобы выиграть один из них, процесс начинается заново. Внезапно, конечный набор правил становится движущейся целью, и игра вырождается в тип социальных взаимодействий, которые составляли бы основу каждого высококлассного реалити-шоу со времен Survivor. Почему, потому что правила меняются, и нет единого мнения о том, как / почему / что они должны представлять, и что более важно, нет ни одного человека, принимающего решения. Каждый игрок в игре, в этот момент, устанавливает свои собственные правила, и за этим следует хаос, пока два игрока не слишком устают, чтобы поддерживать шараду и медленно сдаваться.

Таким образом, если бы книга правил для игры точно представляла одиночку, монопольная книга правил была бы примером злоупотребления.

Как это относится к программированию?

Помимо всех очевидных проблем с безопасностью потоков и синхронизацией, которые возникают с изменяемыми синглетонами ... Если у вас есть один набор данные, которые могут быть прочитаны / обработаны несколькими различными источниками одновременно и существуют в течение всего времени выполнения приложения, Вероятно, сейчас самое время сделать шаг назад и спросить: «Использую ли я здесь правильный тип структуры данных».

Лично я видел, как программист злоупотребляет синглтоном, используя его в качестве своего рода скрученного хранилища базы данных в приложении. Работая непосредственно с кодом, я могу засвидетельствовать, что он был медленным (из-за всех блокировок потоков, необходимых для обеспечения его потоковой безопасности) и кошмаром для работы (из-за непредсказуемой / прерывистой природы ошибок синхронизации), и почти невозможно проверить в условиях «производства». Конечно, система могла бы быть разработана с использованием опроса / сигнализации, чтобы преодолеть некоторые проблемы с производительностью, но это не решило бы проблемы с тестированием и зачем беспокоиться, когда «настоящая» база данных уже может выполнять те же функции в гораздо более надежной среде. / масштабируемым образом.

Опция Singleton - это только , опция, если вам нужно то, что обеспечивает синглтон. Доступный только для чтения экземпляр объекта. Это же правило должно касаться и свойств / элементов объекта.

Видят Википедию Singleton_pattern

, Это также считают антишаблоном некоторые люди, которые чувствуют, что это чрезмерно используется, представляя ненужные ограничения в ситуациях, где единственный экземпляр класса на самом деле не требуется. [1] [2] [3] [4]

Ссылки (только соответствующие ссылки от статьи)

1. ^ Alex Miller. Шаблоны я ненавижу № 1: Singleton, июль 2007
2. ^ Scott Densmore. , Почему одиночные элементы злые , май 2004
3. ^ Steve Yegge. Singletons считал глупым , сентябрь 2004
4. ^ J.B. Rainsberger, IBM. Использование Ваши одиночные элементы мудро , июль 2001

Нет ничего по сути неправильно с шаблоном, предполагая, что он используется для некоторого аспекта Вашей модели, которая является действительно единственной.

я полагаю, что обратная реакция происходит из-за ее злоупотребления, которое, в свою очередь, является вследствие того, что это - самый легкий шаблон, чтобы понять и реализовать.

1. Это легко (ab) используется в качестве глобальной переменной.
2. Классы, которые зависят от одиночных элементов, относительно более тверды к модульному тесту в изоляции.

Когда Вы пишете код с помощью одиночных элементов, скажем, регистратор или соединение с базой данных, и впоследствии Вы обнаруживаете необходимость больше чем в одном журнале или больше чем одной базе данных, you’re в проблеме.

Одиночные элементы делают его очень трудно для перемещения от них до регулярных объектов.

кроме того, it’s слишком легкий для записи неориентированного на многопотоковое исполнение одиночного элемента.

Вместо того, чтобы использовать одиночные элементы, необходимо передать все необходимые вспомогательные объекты от функции до функции. Это может быть упрощено при обертывании всех их в объект помощника, как это:

void some_class::some_function(parameters, service_provider& srv)
{
    srv.get<error_logger>().log("Hi there!");
    this->another_function(some_other_parameters, srv);
}

Первое, что пришло на ум:

1. Они осуществляют плотное соединение. Если Ваш одиночный элемент находится на различном блоке, чем его пользователь, блок использования никогда не может функционировать без блока, содержащего одиночный элемент.
2. Они допускают круговые зависимости, например, блок A может иметь одиночный элемент с зависимостью от блока B, и блок B может использовать одиночный элемент A блока. Все, не повреждая компилятор.