LINUX.ORG.RU

Синглтоны

 ,


1

5

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

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

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

Прав ли я, что основная претензия к синглтону не в том, что он есть, и не в том, что он такой обычно один на все приложение, а в том, что каждый другой объект, которому этот синглтон нужен, магически знает, как этот синглтон называется в глобальном пространстве имен? И чтобы не попадать в категорию «фу быть таким», достаточно передавать этот синглтон параметром всем, кому он полагается для работы (а как он создается на самом-самом верхнем уровне, даже если это типичное foo = MySingleton.getInstance(), никому не интересно)?


P.S. Я точно знаю, что есть хуже синглтона: глобальное состояние, размазанное по пердиллиону модулей. По-моему, это даже хуже goto.

Перемещено mono из talks

★★★★★

Последнее исправление: shimon (всего исправлений: 1)

Ответ на: комментарий от gh0stwizard

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

unt1tled ★★★★
()
Ответ на: комментарий от intelfx

Например, по нескольким синглтонам. %)

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

slackwarrior ★★★★★
()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от Pavval

если есть объект Foo, и два других объекта хранят на него указатели - то это дублирование состояния. Плохо тем, что эти два указателя кто-то как всегда забудет синхронизировать - обнулить/обновить

Зачем обновлять указатель? Обновляется объект. Зачем нужно нулить указатель, мне тоже непонятно.

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

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

А как вы генерируете уникальные численные ID?

в некоторых ЯП помимо классов есть еще функции. их и используют :-)

Virtuos86 ★★★★★
()

И чтобы не попадать в категорию «фу быть таким», достаточно передавать этот синглтон параметром всем, кому он полагается для работы (а как он создается на самом-самом верхнем уровне, даже если это типичное foo = MySingleton.getInstance(), никому не интересно)?

Да, именно так.

yoghurt ★★★★★
()
Ответ на: комментарий от unt1tled

18 анонимусов

Где ж ты так много анонимусов в Development видел?

anonymous
()
Ответ на: комментарий от tailgunner

Зачем обновлять указатель? Обновляется объект. Зачем нужно нулить указатель, мне тоже непонятно.

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

Глядя на опыт 4 лет развития и сопровождения проекта, хорошо вспоминается, как целая куча появлявшихся багов имела причиной именно дублирование состояния - очень уж часто такое нарушение разработчику «наказывалось» багами. Если бы state было размазано, то это не было б так заметно.

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

Ресурсов - вообще нифига. На начальном этапе просто 2-ое шибко умных разработчиков + архитектор для надзора и вполне стандартные сроки на первый релиз. Unit-тестов в природе не было, тестеров от 1:1 до 2:1 на разработчика. Да и сейчас мало что изменилось - ресурсов постоянно не хватает, но качество остается вполне тем же (не считая проблем, которые мы недавно отгребли с одной 3-rd party либой). Я не буду рассказывать сказку «какие у нас умные раработчики работают» - сейчас ничего особенного. Влияет именно дизайн - уж поверь. Stateless код всегда проще писать и он выходит надежнее. Код изменения state локализован и потому нагляден - сложнее ошибиться. Код изменения state еще и асинхронен: вызывающий код не знает, будет ли фактически изменен state в результате запроса - это делает stateless код максимально абстрагированным (только шлет запросы на изменение state и потом уведомляется, если state изменилось).

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

Если бы state было размазано, то это не было б так заметно.

Дублирование состояния во многих случаях вполне естественно и более того - правильно. Возьмём какой-нибудь условный файловый менеджер. Чтобы тупо показать тебе окошко со списокм файлов, там наверняка будут задействованы сущности:

  • Directory - реализует абстракцию над каталогом
  • DirectoryModel - реализует абстракцию модели данных для UI
  • DirectoryView - реализует хреновину, которая умеет показывать данные пользователю

И во всех них будет дублировано состояние.

И как ты с этим будешь бороться?

anonymous
()

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

erfea ★★★★★
()
Ответ на: комментарий от anonymous

И во всех них будет дублировано состояние.

Нет. DirectoryView - stateless. DirectoryModel - или stateless proxy к Directory, или просто объединен с ним/базируется на нем.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

Нет. DirectoryView - stateless.

И на каждый expose и click будешь заново просчитывать весь layout из дохренадцати элементов? А множество selected items как хранить будешь? Нет я конечно понимаю, «любовь к искусству» и всё такое. Но не надо доходить до маразма.

DirectoryModel - или stateless proxy к Directory, или просто объединен с ним/базируется на нем.

Аналогично предыдущему. Есть данные, которые должны быть в model для UI, но им нет места в directory. Предлагаю подумать, какие это могут быть данные.

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

anonymous
()
Ответ на: комментарий от anonymous

Есть данные, которые должны быть в model для UI, но им нет места в directory. Предлагаю подумать, какие это могут быть данные.

Да, мой затуп. Selection и подобные - им место в DirectoryModel. Иногда это следует воспринимать как внутренюю кухню View, иногда нет - зависит от контекста. Но это _доп_ данные относительно Directory, а не его дублирование.

И на каждый expose и click будешь заново просчитывать весь layout из дохренадцати элементов?

А его не надо просчитывать. У тебя и так как не крути - тупо список файлов + per-file аттрибуты. Он уже есть.

Pavval ★★★★★
()
Ответ на: комментарий от Pavval

Иногда это следует воспринимать как внутренюю кухню View, иногда нет - зависит от контекста.

Верно. Например, сортировка. В завимости от задачи, ей место либо в model, либо во view.

Но это _доп_ данные относительно Directory, а не его дублирование.

Эти данные надо держать синхронизированными. По сути, view поддерживает коллекцию из собственных данных + ссылок на элементы model. В конкретной реализации ссылкой может являться указатель, числовой индекс или непрозрачный итератор. Но в любом случае, эту коллекцию ссылок нужно держать синхронизированной.

При этом для простоты ты можешь использовать подход «как только в model что-нибудь изменилось, перестраивать всю коллекцию во view». Однако при столкновении с реальным миром, мы рано или поздно упрёмся в производительность, и тогда этот простейший подход придётся переписать так, чтобы он обновлял только ту часть коллеции, которая реально требует изменении. И тогда уже мантра про «_доп_ данные» перестаёт помогать, потому что комплексность алгоритмов возрастает в разы.

А его не надо просчитывать. У тебя и так как не крути - тупо список файлов + per-file аттрибуты.

Вот тут ты не прав. «тупо список файлов» хранит такие вещи как имя, тип, права доступа и т.п. Для UI тебе надо совсем другое: размеры, координаты и «ссылка но того, кто сумеет это наривать на экран» (имя файла рисует одно, иконку рисует другое и т.п.). В идеале все размеры и координаты тоже надо кэшировать, потому что, например, Pango превращает «строку текста» в "(ширина, высота)" совсем не бесплатно. Алгоритм перехода от «вот список размеров каждого элемента» к «вот список координат каждого элемента» может быть тоже совсем не так тривиален, как кажется на первый взгляд.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.