Что так плохо о одиночных играх?

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

Особенно похоже, что переполнение стека предполагает, что все согласны с тем, что синглтоны - это зло. Зачем?

Пожалуйста, поддержите ваши ответы "фактами, ссылками или конкретными знаниями"

ОТВЕТЫ

Ответ 1

Парафраз от Брайана Баттона:

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

  • Они нарушают принцип единой ответственности: в силу того, что они контролируют свое собственное создание и жизненный цикл.

  • Они по сути заставляют код плотно в сочетании. Это во многих случаях затрудняет их подделку.

  • Они несут состояние в течение всего срока службы приложения. Еще один удар по тестированию, так как вы можете закончить ситуацию, когда нужно заказать тесты, что не является большим для нетипичных тестов. Зачем? Поскольку каждый unit test должен быть независимым от другого.

Ответ 2

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

Контент ресурсов.

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

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

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

вам понадобится singleton.

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

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

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

Ответ 3

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

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

Ответ 4

Misko Hevery, из Google, содержит несколько интересных статей именно по этой теме...

Singletons are Pathological Liars имеет пример единичного тестирования, который иллюстрирует, как одиночные игры могут затруднить определение цепочек зависимостей и начать или протестировать приложение, Это довольно экстремальный пример злоупотребления, но тот момент, который он делает, остается в силе:

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

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

Ответ 5

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

Люди думают, что Синглтон злой, потому что он использует его для глобалов. Именно из-за этой путаницы Синглтон смотрит вниз. Пожалуйста, не путайте Singletons и globals. Если использовать для этой цели, для которой он предназначался, вы получите экстремальные преимущества от шаблона Singleton.

Ответ 6

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

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

Итак, в основном:

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

а не:

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

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

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

Ответ 7

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

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

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

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

Ответ 8

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

Ответ 9

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

Рассмотрим следующую ситуацию: как разработчик вам необходимо создать веб-приложение, которое обращается к базе данных. Чтобы гарантировать, что одновременные вызовы базы данных не конфликтуют друг с другом, вы создаете поток-сохранить SingletonDao:

public class SingletonDao {
    // songleton static variable and getInstance() method etc. omitted
    public void writeXYZ(...){
        synchronized(...){
            // some database writing operations...
        }
    }
}

Итак, вы уверены, что в вашем приложении существует только один синглтон, и вся база данных проходит через этот и только SingletonDao. Теперь ваша производственная среда выглядит так: Single Singleton

До сих пор все в порядке.

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

Many singletons

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

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

Ответ 10

  • Легко (ab) используется как глобальная переменная.
  • Классы, зависящие от синглетонов, относительно сложнее unit test в изоляции.

Ответ 11

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

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

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

  • а. Это вызывает конфликт имен.
  • б. Он разоблачает государство необоснованным образом.

Когда речь заходит о Singletons

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 12

Синглтон не о единственном экземпляре!

В отличие от других ответов, я не хочу говорить о том, что не так с Singletons, но чтобы показать вам, насколько они мощные и потрясающие при правильном использовании!

  • Проблема: Singleton может быть проблемой в многопоточной среде
    Решение: Используйте однопоточный процесс начальной загрузки для инициализации всех зависимостей вашего синглтона.
  • Проблема: трудно издеваться над одиночками.
    Решение: использовать метод Factory pattern для издевательства

Вы можете сопоставить MyModel с классом TestMyModel который его наследует, везде, где MyModel будет введен, вы получите TestMyModel TestMyModel. - Проблема: синглтоны могут вызвать утечку памяти, поскольку они никогда не утилизируются.
Решение: Ну, избавьтесь от них! Внедрите в свое приложение функцию обратного вызова для правильной утилизации синглетонов, вы должны удалить все связанные с ними данные и, наконец, удалить их из Factory.

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

  • Singletons улучшает читабельность: вы можете посмотреть на свой класс и увидеть, какой синглтон он внедрил, чтобы выяснить, каковы его зависимости.
  • Singletons улучшает обслуживание: после того, как вы удалили зависимость из класса, вы только что удалили однокомпонентную инъекцию, вам не нужно переходить и редактировать большую ссылку других классов, которые просто перемещали вашу зависимость (это вонючий код для меня @Jim Burger)
  • Singletons улучшает память и производительность: когда что-то происходит в вашем приложении, и для доставки требуется длинная цепочка обратных вызовов, вы тратите впустую память и производительность, с помощью Singleton вы сокращаете средний уровень и повышаете производительность и использование памяти ( избегая ненужных локальных переменных размещения).

Ответ 13

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

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

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

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

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

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

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

Ответ 14

См. Wikipedia Singleton_pattern

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

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

Ответ 15

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

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

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

  • Убедитесь, что Singleton является потокобезопасным. Это заданное.

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

  • Во время выполнения вашего приложения, где нужно передать одиночные пакеты данному объекту, используйте класс factory, который создает этот объект и имеет класс factory передать экземпляр singleton классу, который нуждается он.

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

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

Ответ 16

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

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

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

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

  • Единый принцип ответственности: Я думаю, что это немного расплывчато и зависит от вашего определения ответственности. Возникает вопрос: зачем добавлять эту конкретную "ответственность" к классу?

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

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

Относительно модульных тестов:

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

Ответ 17

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

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

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

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

Ответ 18

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

С точки зрения pratical, singleton - это время разработки компромисса по сравнению с сложностью.

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

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

Ответ 19

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

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

Ответ 20

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

Ответ 21

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

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

Ответ 22

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

Синглтоны затрудняют переход от них к обычным объектам.

Кроме того, его слишком легко написать однопотоковый однопользовательский режим.

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

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

Ответ 23

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

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

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

Ответ 24

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

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

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

Ответ 25

Синглеты не плохие. Это плохо, когда вы делаете что-то глобально уникальным, что не является глобально уникальным.

Однако существуют "службы области приложения" (подумайте о системе обмена сообщениями, которая заставляет компоненты взаимодействовать) - это CALLS для singleton, класса MessageQueue, который имеет метод "SendMessage (...)".

Затем вы можете делать следующее со всего места:

MessageQueue.Current.SendMessage(новый MailArrivedMessage (...));

И, конечно же, выполните:

MessageQueue.Current.RegisterReceiver(это);

в классах, которые реализуют IMessageReceiver.

Ответ 26

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

Ответ 27

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

В большинстве случаев "singletonity" является деталью реализации для некоторого класса, а не характеристикой его интерфейса. Inversion of Control Container может скрыть этот признак от пользователей класса; вам просто нужно пометить ваш класс как одноэлементный (с аннотацией @Singleton в Java, например) и что он; IoCC сделает все остальное. Вам не нужно предоставлять глобальный доступ к вашему экземпляру singleton, потому что доступ уже управляется IoCC. Таким образом, в IoC Singletons нет ничего плохого.

GoF Singletons в противоположность IoC Синглтоны должны выставлять "singletonity" в интерфейсе методом getInstance(), и поэтому они страдают от всего сказанного выше.

Ответ 28

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

Ответ 29

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

Ответ 30

Образец возникает, когда несколько человек (или команды) приходят к аналогичным или идентичным решениям. Многие люди по-прежнему используют одиночные игры в своей первоначальной форме или используя шаблоны factory (хорошее обсуждение в Alexandrescu Modern С++ Design). Concurrency и трудности в управлении временем жизни объекта являются основными препятствиями, при этом первый легко управляется, как вы предлагаете.

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