Применимы ли паттерны GoF для LISP?

> Собственного мнения основанного на индивидуальном опыте у tg почему-то нет.

Нет. Потому что и в Яве Singleton бесполезен, а в нормальных языках еще и не нужен.

>> Собственного мнения основанного на индивидуальном опыте у tg почему-то нет.

Нет. Потому что и в Яве Singleton бесполезен, а в нормальных языках еще и не нужен.

Ну так каким образом можно организовать глобальную фабрику объектов в проекте, например?

Функцией.

Отсутствие документированной модели будущей системы

компенсируется TDD. Согласен, код превратился бы в груду лапши, но вполне себе майнтебельной рефакторингами

>Функцией.

Насколько я помню религиозные претензии к синглтону, основным поинтом там было то что синглтон - это замаскированная глобальная переменная, а глобальные переменные - это Злоъ. Однако есть такой ньюанс что глобальную фабрику в виде функции невозможно написать без привлечения глобальной переменной, т.к там нужен по меньшей мере один глобальный map вида [идентификатор типа]->[порождающий интерфейс]. Такие дела.

> Насколько я помню религиозные претензии

А набрать в гугле «singleton antipattern» тебе мешает религия, да.

> Может, стоило попробовать написать что-то посложнее расстановщика

бутылок? Что-нибудь с какой-нибудь смешной сотней-другой сущностей?

Да, занимался этим много лет.

После двух-трех таких «итераций» по «взаимодействию с пользователями»

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

Э... Ну я немного научился программировать, да. Вам тоже желаю.

А если ты скажешь, что ты готов удержать в голове всю сотню сущностей

с их атрибутами, методами, связями и иерархией наследования

Зачем всё помнить то? Хотя, знаете, бывает открою код, который писал 10 лет назад, немного на него смотрю и быстро всё вспоминаю. Я какой-то особенный?

Расскажите мне, как вы собираетесь реализовывать подписку компонентов (например, виджетов) на события (например, нажатие кнопки) в функциональных языках.

на здоровье

>Что особенно удивительно, класс URL написал лично Гослинг.

действительно удивительно. все что написал лично Гослинг, попытались выпилить еще в версии 1.2, и это почти получилось. а вот за УэРэЛ не доглядели :(((((

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

>Расскажите мне, как вы собираетесь реализовывать подписку компонентов (например, виджетов) на события (например, нажатие кнопки) в функциональных языках.

про реактивное программирование слышал? видимо нет.

Ну так каким образом можно организовать глобальную фабрику объектов в проекте, например?

Зачем она вообще нужна?

Есть класс-сервис. Есть его зависимости. Во время или после создания класса инициализируются его зависимости.

Что то вроде Spring-а (сам по себе Spring слишком переусложнён, но подход правильный).

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

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

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

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

тебя послушать, дак «рабочий код» = «говнокод» :)))))

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

Вроде всё развернул. Глобальные объекты видел. Синглтоны видел. Синглтоны с обоснованным применением - не видел. Есть синглтон = класс не тестируем почти всегда, имеет ненужные зависимости, может вести себя неожиданным образом.

>А набрать в гугле «singleton antipattern» тебе мешает религия, да.

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

тебя послушать, дак «рабочий код» = «говнокод»

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

имеет ненужные зависимости, может вести себя неожиданным образом.

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

> Расскажите мне, как вы собираетесь реализовывать подписку компонентов (например, виджетов) на события (например, нажатие кнопки) в функциональных языках.

не чисто функционально, но приятного просмотра, да

http://www.youtube.com/watch?v=SsBxcpkyMMw

>Есть класс-сервис. Есть его зависимости. Во время или после создания класса инициализируются его зависимости.

Ну тогда получается такой реестр в котором прописаны все зависимости для всего. И объектная модель СОМ соответственно.

>> А набрать в гугле «singleton antipattern» тебе мешает религия, да.

А зачем?

Вечно забываю, что ты наркоман с атрофированным мозгом.

Ну тогда получается такой реестр в котором прописаны все зависимости для всего. И объектная модель СОМ соответственно.

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

А что плохого с концепцией COM? Реализация может не самая лучшая, по крайней мере при использовании C или C++, да и GUID-ы читабельности не прибавляют, но в итоге вся ОС на этом COM-е работает и не жужжит, свою задачу эта технология вполне выполнила.

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

>А что плохого с концепцией COM?

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

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

1) в глобальных переменных;

Вот уж это точно антипаттерн. Самый крутой паттерн для хранения состояния в функциях - это хаскелловские монады.

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

Для функции нужно меньше извращаться.

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

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

>> 1) в глобальных переменных;

Вот уж это точно антипаттерн.

А ты, наверное, из тех, кто считает goto антипаттерном?

Самый крутой паттерн для хранения состояния в функциях - это хаскелловские монады.

А тем, кому крутизна пох, подойдет обычный карринг.

А ты, наверное, из тех, кто считает goto антипаттерном?

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

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

А тем, кто хаскелл неосилил, подойдет обычный карринг.

Fix.

Но ведь по ссылке всё только для Haskell, а я просил для Common Lisp. Не привели. С другой стороны, если заглянуть в CL-GTK2, то там всё сделано типично по паттерну Observer. Таким образом, показана применимость паттерна Observer к Common Lisp.

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

> Не. Просто дописать необходимые реализации методов. В CLOS нет интерфейсов, а методы не принадлежат классам.

Но ведь это влечёт tight coupling, то, для борьбы с которым и предназначены большинство паттернов.

Тем не менее, будем считать, что паттерны Singleton и Adaptor низвергнуты! В то же время, применимость паттерна Observer подтверждается: он используется в CL-GTK2 в явном виде. Пакет bordeaux-threads, в свою очередь, является демонстрацией двух других паттернов: Bridge и Facade. Но остаются ещё 18!

Creational patterns: Abstract Factory, Builder, Factory method, Prototype, Singleton
Structural patterns: Adaptor, Bridge, Composite, Decorator, Facade, Flyweight, Proxy
Behavioral patterns: Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template method, Visitor

> А тем, кто хаскелл неосилил, подойдет обычный карринг.

Fix.

Прежде чем фиксить фразы таким образом, начни зарабатывать деньги именно Хаскеллем %)

Расскажите мне, как вы собираетесь реализовывать подписку компонентов (например, виджетов) на события (например, нажатие кнопки) в функциональных языках.

Но ведь по ссылке всё только для Haskell

ты уж определись - тебе про функциональные языки или про CL надо? если первое, то вот тебе по ссылке техника, которая позволяет решать указанную задачу - причём значительно более элегантным методом (смотри раздел mempty/mappend, например)

Прежде чем фиксить фразы таким образом, начни зарабатывать деньги именно Хаскеллем %)

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

Прежде чем фиксить фразы таким образом, начни зарабатывать деньги именно Хаскеллем %)

Огласи сколько мне надо заработать хаскелем, чтоб ты согласился с моим утверждением :)

> ты уж определись - тебе про функциональные языки или про CL надо?

Для тех кто не умеет читать, тред называется «Применимы ли паттерны GoF для LISP?» - я вообще не понимаю, чего вы сюда с Хаскелем припёрлись. Хотя... раз уж припёрлись, то выскажите своё мнение о применимости паттернов GoF к Haskell. Тоже из принципа считаете их костылями и баззвордами?

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

Спасибо не надо. Ни для лиспа, ни для хаскеля. Для Common Lisp мы уже выяснили, что Observer там используется вовсю. А Haskell меня в данный момент не особо интересует.

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

Этот весь аццкий гимор ныне заменен IoC (тоже паттерн), который нарисовать как два пальцо обоссать. В отлчие от сиглтонов и God (is evil) оно позволяет кое как разобраться с инициализацие й и зависимостями.

_________

//wfrr

>> ты уж определись - тебе про функциональные языки или про CL надо?

Для тех кто не умеет читать, тред называется «Применимы ли паттерны GoF для LISP?»

jtootf, по-моему, тебя сделали. ;)

> Огласи сколько мне надо заработать хаскелем, чтоб ты согласился с моим утверждением :)

Твоя dayjob должна состоять из работы на Хаскеле хотя бы на 51%, и должна приносить тебе доход, достаточный для содержания семьи. Размер дохода не имеет значения - его просто должно хватать.

> а от источника заработка что, сильно меняется объективная истинность высказываемых утверждений?

Нет.

я не в контекст

А я в контексте.

> Хотя... раз уж припёрлись, то выскажите своё мнение о применимости паттернов GoF к Haskell.

http://blog.ezyang.com/2010/05/design-patterns-in-haskel/

Тоже из принципа считаете их костылями и баззвордами?

Тащемта костылями их считают GoF.

>>Singleton, Flyweight,

Это антипаттерны 8)

А почему Flyweight - это антипаттерн?

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

Что-нибудь с какой-нибудь смешной сотней-другой сущностей? Ах, не предлагают... Жалко!

Да ты сам такое то писал? А если писал то проектировал все это? Взрослые дядьки небось бабло пилят да с умным видом бесполезные диаграммы малюют, а ты повелся.

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

Есть более интересные и полезные паттерны, чем GoF. GoF - детсад, не стоит на них заострять внимание.

С другой стороны, если заглянуть в CL-GTK2, то там всё сделано типично по паттерну Observer.

Тебя совсем не смущают буквы после дефиса и то, что данный пакет всего лишь обертка к ним?

> Тащемта костылями их считают GoF.

Пруф?

> А почему Flyweight - это антипаттерн?

Потому что wfrr не читал книжку, очевидно же :)