Singleton — паттерн или антипаттерн?

Проектирование и рефакторинг*

10.55%
(46): Singleton — это по сути те же глобальные переменные, то есть ужасное зло

8.94%
(39): Singleton — это по сути те же глобальные переменные, то есть великое добро

7.8%
(34): Singleton — это совсем не глобальные переменные, но всё равно ужасное зло

45.18%
(197): Singleton — это совсем не глобальные переменные, и к тому же великое добро

27.52%
(120): Что такое Singleton?

Проголосовало 436 человек. Воздержалось 164 человека.

–2

29 июля 2011, 18:59

gvsmirnov 32,1

комментарии (35)

+11

kk86 29 июля 2011, 19:05 #

Синглтон — зло, когда применён не к месту. Разве нет?

Doggy 29 июля 2011, 19:09 # ↑

[Полный перебор значений] — зло, когда применено не к месту. Разве нет?

kk86 29 июля 2011, 19:17 # ↑

Да, мой комментарий был «капитанством». Но разве при этом комментарий не справедлив? В вариантах ответов — одни крайности: «великое добро», «ужасное зло». Просто надо усиленно думать при применении любого кусочка кода. К синглтону это тоже относится, даже сильнее. Лично я синглтоны употребляю только при острой необходимости.

TheShock 29 июля 2011, 21:48 # ↑

Проблема в том, что простота этого паттерна стала причиной ПОСТОЯННОГО применения Синглтона не к месту.
Хотя, вот лично я, не могу представить, когда он может быть нужен на практике.

TheShock 29 июля 2011, 21:51 # ↑

Ну и да, Синглтон имеет кучу недостатков:

1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров.
2. Зависимость обычного класса от синглтона не видна в публичном контракте класса. Так как обычно экземпляр синглтона не передается в параметрах метода, а получается напрямую, через getInstance(), то для выявления зависимости класса от синглтона надо залезть в тело каждого метода — просто просмотреть публичный контракт объекта недостаточно. Как следствие: сложность рефакторинга при последующей замене синглтона на объект, содержащий несколько экземпляров.
3. Глобальное состояние. Про вред глобальных переменных вроде бы уже все знают, но тут та же самая проблема. Когда мы получаем доступ к экземпляру класса, мы не знаем текущее состояние этого класса, и кто и когда его менял, и это состояние может быть вовсе не таким, как ожидается. Иными словами, корректность работы с синглтоном зависит от порядка обращений к нему, что вызывает неявную зависимость подсистем друг от друга и, как следствие, серьезно усложняет разработку.
4. Наличие синглтона понижает тестируемость приложения в целом и классов, которые используют синглтон, в частности. Во-первых, вместо синглтона нельзя подпихнуть Mock-объект, а во-вторых, если синглтон имеет интерфейс для изменения своего состояния, то тесты начинают зависеть друг от друга.

adontz 29 июля 2011, 23:52 # ↑

2. В случае ServiceProvider'ов зависимость тоже не видна.
3. Уместно применённый синглтон, только stateless.

barker 29 июля 2011, 19:11 #

Мой вариант: Singleton — это совсем не глобальные переменные, и… иногда можно

isden 29 июля 2011, 20:21 # ↑

> и… иногда можно

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

theRavel 29 июля 2011, 19:12 #

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

–2

mark_ablov 29 июля 2011, 19:16 #

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

shai_xylyd 29 июля 2011, 19:23 #

Сингелтон убивает композицию.

Speedimon 29 июля 2011, 20:17 # ↑

Конечно, Single Tone — это монофонический синтезатор, звучание же грубое и ужасное, любую компощицию похоронит.

nihi_l_ist 29 июля 2011, 19:24 #

Кстати статья для интересующихся: Implementing the Singleton Pattern in C# Скита (Многие ее уже видели и используется там специфика C#, но всеж).

Ernado 30 июля 2011, 01:34 # ↑

Спасибо за ссылку!
Я например еще не эту видел статью. Про Lazy не знал. Интересная штука.

eyeofhell 29 июля 2011, 19:27 #

ИМХО, как и goto в C++ — хоршая штука если точно знаешь где и как его применять. Даже не так — ТОЧНО знаешь :). Во всех остальных случаях, увы, порождает спагетти-код :(.

mark_ablov 29 июля 2011, 19:30 # ↑

отлично, а причем здесь синглтон?

eyeofhell 29 июля 2011, 19:34 # ↑

Даже не знаю как ответить, вы меня прямо в тупик поставли :). Потому что гладиолус?

gaelpa 29 июля 2011, 19:34 # ↑

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

eyeofhell 29 июля 2011, 19:40 # ↑

Да легко.
— Использование синглтона для хранения кэша спрайтов. «Ну он же общий для всех!».
— Использование синглтона для доступа к настройкам приложения. Смешно? А вот когда их обновлять в рантайме приходится, становится не смешно :).
— Использование синглтона для доступа к базе данных. Да-да, то самое, эталонное. Как потом красив и прекрасен код, когда баз данных становится больше одной…

CLR 29 июля 2011, 19:48 # ↑

В Cocoa у Apple кстати настройки приложений сделаны через синглтон — крайне удобно.

eyeofhell 29 июля 2011, 19:53 # ↑

Я помню. И именно поэтому большая часть программ в App Store осень мучительно переживают смену этих самых настроек в программе и требуют выхода и входа для их применения ^_^.

CLR 29 июля 2011, 19:56 # ↑

Вы про Cocoa Touch? Я если честно не в курсе в чем там отличии, но предполагаю что просто кривой какой-то кривой.

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

eyeofhell 29 июля 2011, 20:01 # ↑

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

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

CLR 29 июля 2011, 20:23 # ↑

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

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

А перезаходить в приложения (я уж почитал что там к чему в iOS) — это действительно кривой код новичков. Им нужно почитать что-то вроде «Cocoa Design Patterns».

gaelpa 29 июля 2011, 20:01 # ↑

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

eyeofhell 29 июля 2011, 20:03 # ↑

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

vokbuz 29 июля 2011, 19:45 #

Паттерн сам по себе вполне не плох. А вот реализации иногда заставляют плакать.

leventov 29 июля 2011, 20:07 #

Считаю злом.
Исчерпывающее обсуждение в java-контексте:
stackoverflow.com/questions/28241/java-singleton-vs-static-is-there-a-real-performance-benefit

Bambr 29 июля 2011, 20:11 #

На мой взгляд, ответ не однозначен. Я разрабатываю на perl, он вполне позволяет обозвать синглтоновский метод для получения экземпляра объекта как угодно. Если я называю этот метод так же, как типовой конструктор — new — то в будущем при необходимости могу спокойно отказаться от паттерна, или поменять логику его работы, и снаружи объекта об этом никто не узнает. Есть метод, который возвращает экземпляр, а уж откуда он берется — это его личное дло. Это — добро, т.к. оно дает гибкость, не забирая ничего взамен. Если ЯП не позволяет проделать такой трюк (кажется, в той дискуссии фигурировал С#, но уже не уверен), и я вынужден по-книжному называть метод именем instance, то уже по названию метода видно откуда он взялся и что делает, и это не совсем добро. Но все-таки лучше глобальных переменных, т.к. вы все еще можете изменить реализацию этого метода, хотя если метод с названием instance внезапно начнет возвращать разные объекты, вас проклянут потомки…

LoneCat 29 июля 2011, 20:37 #

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

asm0dey 29 июля 2011, 23:11 # ↑

А если у меня есть универсальная фабрика, которая может произвести любой объект с любыми параметрами и ее синглтон — это тоже неправильно?

VolCh 30 июля 2011, 00:10 #

Когда альтернатива глобальные переменные — я выберу синглтон, получаемый через фабрику (использование в 100500 местах программы $obj = ClassName::getIntstance() мне почему-то нравится куда меньше, чем $className='ClassName'; $obj = Fabric::get($className);

GrigoryPerepechko 21 февраля 2012, 11:49 # ↑

Не пишите так больше пожалуйста.

gvsmirnov 21 февраля 2012, 13:57 # ↑

Вам не нравится $объ = Материя:: получить($классИмя)? :)

AxisPod 30 июля 2011, 05:16 #

Главное применять в нужном месте, а не везде где хочется.

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

Лучшее ^{за 24 часа} ↓

Находим admin + shell на *******.alfabank.ru с помощью Google

С Днём Рождения, Хабр!

Жизнь без объектов

Локализация точки в выпуклом многоугольнике

Идентификация пользователя по голосу

Алгоритм Хаффмана на пальцах

Разрабатываем модуль PHP на C++. Часть 1: экскурс в мир Zend Engine 2

PocketLint: Facebook намерена приобрести Opera?

Полнометражный документальный фильм о демосцене: The Art Of The Algorithms

Создание анимированного 3D Шара на CSS3

« все лучшие

Обращение зависимостей и порождающие шаблоны проектирования 13.05.2011

Шаблоны проектирования в автоматном программировании 02.12.2011

Шаблоны проектирования, паттерн «стратегия» 18.11.2011

Функциональное мышление: Функциональные шаблоны проектирования, часть 2 25.04.2012

Функциональное мышление: Функциональные шаблоны проектирования, часть 1 23.04.2012

Шаблон Bridge дополнительные штрихи 27.02.2012

Бесплатная электронная книга по шаблонам проектирования на украинском языке 15.02.2012

DesignPatterns, шаблон Interpreter 16.01.2012

Шаблоны проектирования при разработке под Android. Часть 3 — Пользовательский интерфейс, тестирование, AndroidMock 01.11.2011

Прямой эфир ↓

yumitsu → Вышел непривязанный jailbreak для iOS 5.1.1 Absinthe 2.0.1 83

Kobs → Продемонстрированы возможности камеры Project Glass от Google 62

Lux_In_Tenebris → Строим карту популярности дней рождения с помощью Processing и VK API 17

opposite → Всегда рядом, или почему я ушел от Сбербанка 149

merlin_rterm → Уже не Первый 90

Caravus → WarCraft III / Dota кратко о создании чита 48

K0Ka → С Днём Рождения, Хабр! 199

kuzemchik → Запрограммируем вакансию 13

driessen → thn.gs — для того, чтобы не помнить 112

merlin_rterm → Google Drive может лишиться логотипа 113

Компания дня Компания, чей пост набрал максимальное количество баллов<br>
среди всех опубликованных в корпоративных блогах постах за <br>
прошедшие сутки. Учитываются посты, для которых истек срок голосования <br>(3 дня с момента публикации).