Синглтоны: хороший дизайн или костыль? [закрыто]

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

Пожалуйста, укажите причины своего мнения, а не просто "Singletons для ленивых программистов!"

Вот довольно хорошая статья по этому вопросу, хотя она против использования Singletons: Scientificninja.com: Performant-Singletons .

У кого-нибудь есть другие хорошие статьи на них? Может быть, в поддержку синглетонов?

15.08.2008 00:39:01
23 ОТВЕТА

Цель Singleton - обеспечить, чтобы у класса был только один экземпляр, и предоставить глобальную точку доступа к нему. В большинстве случаев основное внимание уделяется одной точке экземпляра. Представьте, если бы это называлось Globalton. Это звучит менее привлекательно, так как это подчеркивает (обычно) негативные коннотации глобальной переменной.

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

26
15.08.2008 00:48:40
Так почему же класс должен убедиться, что у него есть только один экземпляр? Это в значительной степени противоречит целям объектно-ориентированного программирования.
Patrick Glandien 10.03.2009 09:32:19
Обычно вы хотели бы только одно средство регистрации? Или вы упаковываете какую-то вуду-DLL, и вы не хотите, чтобы была возможность загрузить DLL дважды?
Calyth 6.10.2009 20:30:47
@Calyth, но зачем делать это обязанностью класса, если она сама является системной ответственностью. (любой экземпляр объекта будет работать нормально, но система может выйти из строя, если не будет соблюден единственный живой объект с ограничением по времени)
Rune FS 8.09.2010 09:34:21
@RuneFS Потому что мне просто нужно написать код один раз в классе для обеспечения единства. Если бы система обеспечивала это, мне пришлось бы писать код везде в системе для обеспечения единства. Намного проще протестировать один класс для одного конкретного поведения, чем 100 различных классов, чтобы убедиться, что все они отражают это одно поведение.
iheanyi 12.06.2014 19:14:20
@iheanyi ты упускаешь суть. Вы поместили ответственность в «100 классов», это не дизайн, который сделал это системной ответственностью. Я выступаю за возложение ответственности на любую часть системы, которая отвечает за создание экземпляров (IoC или аналогичная)
Rune FS 13.06.2014 07:40:06

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

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

1
15.08.2008 01:48:54
Синглтоны смешивают обязанности. Обеспечение того, чтобы когда-либо существовало только X экземпляров чего-либо, является обязанностью системы делать то, что когда-либо является функциональностью объекта, является ответственностью объекта.
Rune FS 13.06.2014 08:00:19

Синглтон - это просто набор глобальных переменных в модном костюме.

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

31
15.08.2008 02:12:11
глобальные переменные ... и методы. глобальный объект даже ...
dqhendricks 28.04.2011 17:23:21
Синглтон не обязательно должен быть настоящим глобальным объектом.
iheanyi 12.06.2014 19:22:12

У Google есть Singleton Detector для Java, который, как я считаю, изначально был инструментом, который должен запускаться для всего кода, созданного в Google. В двух словах причина для удаления Singletons:

потому что они могут затруднить тестирование и скрыть проблемы с вашим дизайном

Более подробное объяснение см. В разделе « Почему синглтоны противоречивы » от Google.

37
15.09.2008 17:19:34
Я подозреваю, что говорить о том, что это «должно выполняться на всем коде, созданном в Google», не стоит. (Во-первых, они, вероятно, используют другие языки.)
Tyler 15.09.2008 17:40:06
Я считаю, что Java, Python и C ++ являются одобренными языками в Google.
Brian 26.09.2008 13:44:02
Они также могут использовать JavaScript: steve-yegge.blogspot.com/2007/06/rhino-on-rails.html
CTT 18.02.2009 19:35:47
У Google также есть бухгалтерия; значит ли это, что каждый разработчик должен его получить? Решение запретить определенные конструкции - это деловое решение со стороны Google, которое больше говорит об их внутренней среде. Без сомнения, некоторый вручную настроенный машинный код все еще запутан, но по деловым причинам не только кто-то должен это делать.
Dustman 16.02.2010 20:01:34
Пойди и прочитай какой-нибудь код Google, они не живут по этому правилу.
jkp 6.06.2010 12:03:31

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

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

1
15.08.2008 02:50:15

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

Я должен не согласиться с Орионом, хотя, в большинстве случаев я видел, как синглтоны переусердствовали в том, что это не глобальные переменные в одежде, а скорее глобальные услуги (методы) в одежде. Интересно отметить, что если вы попытаетесь использовать Singelton в SQL Server 2005 в безопасном режиме через интерфейс CLR, система пометит код. Проблема в том, что у вас есть постоянные данные за пределами любой транзакции, которая может выполняться, конечно, если вы сделаете переменную экземпляра доступной только для чтения, вы сможете обойти проблему.

Эта проблема привела ко многим переделкам для меня за один год.

5
15.08.2008 02:54:53
Я никогда не понимал, почему люди так любят этот шаблон. Я думаю, это потому, что он «позволяет» использовать глобальные переменные, что избавляет вас от необходимости переосмысливать дизайн. За исключением, конечно, это не так.
Chris Huang-Leaver 7.07.2009 11:07:13

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

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

Затем я создал одноэлементный класс с именем company , который инкапсулировал все о месте, и к моменту открытия системы он был полностью заполнен данными.

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

Кроме того, это была фиксированная общесистемная легкодоступная точка для хранения данных компании.

0
15.08.2008 03:40:26
Я не голосовал против этого, но я хотел бы объяснить, почему кто-то мог проголосовать против. Синглтон не лучший / единственный способ кеширования данных. Класс с десятками обязанностей не «должным образом» разработан.
Amy B 19.09.2008 01:39:38
Похоже, ваш синглтон должен был быть отдельной программой. Интерфейс - это сервисный уровень.
gtrak 12.10.2010 21:43:29

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

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

Я вижу по крайней мере 3 набора классов, в которых я обычно проектирую, но я предпочитаю отдавать предпочтение более мелким более простым объектам, которые очень хорошо выполняют узкий набор задач. Я знаю, что это не природа большинства программистов. (Да, я работаю над 5000 строчными монстрами каждый день, и я особенно люблю 1200-строчные методы, которые пишут некоторые люди.)

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

2
15.08.2008 05:22:48

Священные войны! Хорошо, дайте мне посмотреть .. Последний раз, когда я проверял дизайн полиции сказал ..

Синглеты плохие, потому что они мешают автоматическому тестированию - экземпляры не могут быть созданы заново для каждого теста. Вместо этого логика должна быть в классе (A), который может быть легко создан и протестирован. Другой класс (B) должен отвечать за ограничение создания. Единый принцип ответственности на первый план! Это должно быть командное знание, что вы должны пройти через B, чтобы получить доступ к A - своего рода командное соглашение.

Я согласен в основном ..

5
23.08.2008 17:22:32

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

Синглтон должен использоваться только для одного экземпляра данного класса. Хранилище шаблонов имеет отличную информацию о Синглтоне .

8
27.08.2008 01:20:26

Я использовал синглеты несколько раз в связке со Spring и не считал это опорой или ленивостью.

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

В моем случае синглтон содержал критерии конфигурации клиента - местоположение файла CSS, критерии подключения БД, наборы функций и т. Д. - специфичные для этого клиента. Эти классы были созданы и доступны через Spring и использовались пользователями с одинаковой конфигурацией (т.е. 2 пользователями из одной компании). * ** Я знаю, что есть название для этого типа приложения, но оно ускользает от меня *

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

1
27.08.2008 18:14:06
это хороший способ сделать это. Проблемы приходят со статическими аксессорами для синглетонов.
gtrak 12.10.2010 21:45:17

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

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

Еще лучше использовать инверсию контрольного контейнера! Большинство из них позволяют вам отделить поведение экземпляров от реализации ваших классов.

0
15.09.2008 17:24:18

В защиту синглетонов:

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

Против синглетонов:

  • В C ++ нет хорошего способа автоматической очистки после синглетонов. Есть обходные пути и немного хакерские способы сделать это, но просто не существует простого, универсального способа убедиться, что деструктор вашего синглтона всегда вызывается. Это не так ужасно для памяти - просто подумайте об этом как о более глобальных переменных для этой цели. Но это может быть плохо, если ваш синглтон выделяет другие ресурсы (например, блокирует некоторые файлы) и не освобождает их.

Мое собственное мнение:

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

56
17.12.2009 00:09:49
В первом пункте предположение является довольно резким, обычно выделение кучи происходит не так, как создаются синглтоны (по крайней мере, в C ++).
Joris Timmermans 16.03.2009 14:27:06
Я не уверен в этом, MadKeithV. Существует стандартный шаблон, в котором функция-член, скажем, MyClass * MyClass :: get_instance (), проверяет статический указатель на член и, если он равен NULL, вызывает new для выделения (в куче) общего экземпляра. Как бы синглтон жил в другом месте?
Tyler 1.08.2009 13:28:39
Об обратной стороне C ++: взгляните на синглтон Meyers.
Paul Manta 27.08.2011 06:05:54
@Tyler: я только что натолкнулся на код, который поддерживает вид @MadKeithV, не использующий кучу для синглтона. class MySingleton { public: static MySingleton &getInstance() { static MySingleton instance; return instance; } private: MySingleton(); ~MySingleton(); }; , Ссылка - stackoverflow.com/questions/2593324/c-singleton-class
Forever Learner 25.04.2012 18:03:04
Тег вопроса: «язык-независимый». Первый пункт в ответе: «у глобалов нет стандартного порядка инициализации, ... синглтоны (при условии, что они размещены в куче) создаются после всех глобалов» . Это, конечно, не языковые комментарии.
Mark Amery 24.12.2014 00:03:07

В блоге Google Testing есть три довольно хороших сообщения в блоге о Singletons Мишко Хевери .

  1. Синглтоны - патологические лжецы
  2. Куда ушли все синглтоны?
  3. Первопричина синглетонов
23
15.09.2008 17:52:06
ух, действительно интересные вещи, но я хочу решения! :-) txn
Sander Versluys 2.09.2009 14:33:43
Я думаю, что одним из «решений» является внедрение зависимостей, которое фактически обрабатывает внедрение экземпляра для вас и освобождает синглтон от анти-паттерна. :) Проверьте Guice! code.google.com/p/google-guice
Bleadof 3.09.2009 19:18:31
1. Проблема с первой статьей. Вы можете просто сделать синглтон аргументом конструктора и полностью решить проблему в статье. 2. Синглтон не должен быть глобальным. Поэтому замените «общие объекты» в статье на Singleton, и все по-прежнему работает. 3. Только когда вы дойдете до третьей статьи, он хеджирует все дерьмо, заявленное в первых двух, чтобы сказать: «О, плохая вещь, о которой я говорил, это шаблон проектирования, где доступ к« синглтону »действительно глобален. Дух. Итак, вы написали 3 статьи, чтобы просто сказать, что глобальные перемены плохие, особенно когда используются сложными способами
iheanyi 12.06.2014 19:17:25

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

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

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

2
16.09.2008 10:55:57
Кто-нибудь хочет поделиться причиной отрицательных голосов?
Bill Michell 5.06.2009 14:22:23
Билл, должен сказать, мне тоже интересно? У меня нет большого опыта, но ваше мнение о проблемах параллелизма звучит для меня логично?
Stein Åsmul 10.07.2009 17:48:21
Что не так с использованием синглетонов в ленивой инициализации, где синглтон является, например, помощником? Я не говорю, что вы не правы, я просто спрашиваю.
Flavius 21.01.2010 12:32:54
Проблема заключается в использовании двойной проверки блокировки для их инициализации. См. En.wikipedia.org/wiki/Double-checked_locking - например, в Java простая реализация с двойной проверкой не является поточно-ориентированной и поэтому может привести к сложным для диагностики сбоям.
Bill Michell 4.02.2010 13:34:40

Например, в синглетах, например, в Java, страшно то, что в некоторых случаях вы можете получить несколько экземпляров одного и того же синглтона. JVM однозначно идентифицирует на основе двух элементов: полное имя класса и загрузчик классов, ответственный за его загрузку.

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

0
17.09.2008 20:04:45
Если один и тот же класс загружается двумя загрузчиками классов, это не тот же класс.
Tom Hawtin - tackline 28.09.2008 20:12:22
Если класс загружается загрузчиками классов A и B, но они оба реализуют один и тот же интерфейс, загруженный загрузчиком классов C, то вы можете передавать экземпляры класса из загрузчиков классов A и B пользователям C. Таким образом, программа может использовать два экземпляра класса синглтон в то же время.
Esko Luontola 18.02.2009 20:20:42

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

Я бы сказал, что синглтон следует использовать, если модель предметной области диктует (а не «предполагает»), что она существует. Все остальные случаи являются просто единичными экземплярами класса.

6
22.09.2008 11:48:58

Пишите нормальные, тестируемые, инъецируемые объекты и позволяйте Guice / Spring / что угодно обрабатывать создание экземпляров Шутки в сторону.

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

0
18.02.2009 19:25:37

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

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

3
18.02.2009 19:49:34

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

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

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

Создание только одного экземпляра - это хорошо . Вы просто создаете один экземпляр при запуске программы, а затем передаете указатель на этот экземпляр всем другим объектам, которые в этом нуждаются. Инфраструктуры внедрения зависимостей делают это легко - вы просто настраиваете область объекта, а структура DI позаботится о создании экземпляра и передаче его всем, кто в нем нуждается. Например, в Guice вы должны аннотировать класс с помощью @Singleton, а структура DI создаст только один экземпляр класса (для каждого приложения - в одной JVM может быть запущено несколько приложений). Это облегчает тестирование, потому что вы можете создать новый экземпляр класса для каждого теста и позволить сборщику мусора уничтожить экземпляр, когда он больше не используется. Ни одно глобальное состояние не будет передаваться из одного теста в другой.

Для получения дополнительной информации: Чистые переговоры по коду - «Глобальное государство и синглтоны»

4
18.02.2009 20:13:19
Что касается очистки таких объектов между тестами, почему это должно быть сложно? Почему нельзя уничтожить объект, а на его месте появился новый? Отсутствие возможности для этого является проблемой реализации, а не проблемой самого шаблона.
Dustman 16.02.2010 20:16:36
Проблема заключается в том, чтобы не забывать всегда чистить объекты после теста. Кроме того, поскольку код может получить доступ к статическому синглтону из любой точки мира, невозможно, просто взглянув на тестовый код, увидеть, использует ли какой-то класс статический синглтон, поэтому очень легко забыть некоторые зависимости. Сравните это с внедрением зависимостей, где все зависимости должны быть объявлены явно в конструкторе - код даже не скомпилируется, если некоторая зависимость будет забыта.
Esko Luontola 16.02.2010 21:02:58

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

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

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

Недостатки:

  • Вы соединяетесь с одним классом по всему коду, который вызывает singleton
    • Создает трудности с модульным тестированием, поскольку сложно заменить экземпляр на фиктивный объект
    • Если код необходимо реорганизовать позже из-за необходимости более чем одного экземпляра, это более болезненно, чем если бы класс singleton был передан в объект (используя интерфейс), который его использует

Преимущества:

  • Один экземпляр класса представлен в любой данный момент времени.
    • По замыслу вы обеспечиваете это
  • Экземпляр создается, когда это необходимо
  • Глобальный доступ является побочным эффектом
19
19.02.2009 22:33:43
«Глобальный доступ - это побочный эффект». Я рад, что кто-то указал на это. Глобальный аспект, вероятно, самая неправильно используемая часть синглтона
RobS 8.02.2010 22:24:33
Могу поспорить, что мнение Эрика Гаммы о синглетах пришло из большого с трудом заработанного опыта.
gtrak 12.10.2010 21:34:04
Этот ответ заслуживает того, чтобы быть на вершине ИМО.
Frosty Z 28.09.2011 10:33:11
@RobS Я не понимаю. Как вы можете использовать Singleton без доступа к его глобальному экземпляру и сохранить преимущества, которые вы связали? Глобальный доступ не является побочным эффектом.
Shoe 19.06.2014 10:15:17
@Джеффри Точка может быть лучше названа «глобальной ссылкой». В первоначальном ответе об этом ясно сказано: «Если код необходимо реорганизовать позднее из-за необходимости более одного экземпляра, это более болезненно, чем если бы в объект был передан класс singleton»
RobS 3.07.2014 14:11:16

Птенцы копают меня, потому что я редко использую синглтон, и когда я делаю это, обычно что-то необычное. Нет, серьезно, я люблю шаблон синглтона. Ты знаешь почему? Потому что:

  1. Мне лень.
  2. Ничто не может пойти не так.

Несомненно, «эксперты» расскажут о «модульном тестировании» и «инъекции зависимостей», но это все нагрузка на почки динго. Вы говорите, что синглтон трудно для модульного тестирования? Нет проблем! Просто объявите все публично и превратите свой класс в веселый дом всемирного добра. Вы помните шоу Highlander из 1990-х? Синглтон вроде как, потому что: A. Он никогда не умрет; и Б. Там может быть только один. Так что перестаньте слушать всех этих ди-джеев и реализуйте свой синглтон без промедления. Вот еще несколько веских причин ...

  • Все делают это.
  • Шаблон синглтона делает вас непобедимым.
  • Синглтон рифмуется с «победа» (или «веселье» в зависимости от вашего акцента).
16
17.12.2009 00:05:54

Я много читаю о «Синглтоне», его проблемах, когда его использовать и т. Д., И вот мои выводы до сих пор:

  • Неразбериха между классической реализацией Singleton и реальным требованием: ПРОСТО ОДИН МОМЕНТ КЛАССА!

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

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

  • Не TDD . Если вы делаете TDD, зависимости извлекаются из реализации, потому что вы хотите, чтобы ваши тесты были легко написаны. Это делает вашу объектную модель лучше. Если вы используете TDD, вы не напишите статический GetInstance =). Кстати, если вы будете думать об объектах с четкими обязанностями вместо классов, вы получите тот же эффект =).

1
17.12.2009 00:02:55
Может ли downvoter, пожалуйста, уточнить причины его понижения? Спасибо за ответ!
bloparod 30.08.2011 18:02:45