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

> Есть более интересные и полезные паттерны, чем GoF.

Список в студию.

> Да ты сам такое то писал?

Писал.

А если писал то проектировал все это?

Проектировал.

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

Одним из этих «дядек с умным видом» был я сам. Из «бесполезных диаграмм» генерировались 1) схема БД, 2) скелеты классов Java и С++, 3) маппинг для ORM, 4) документация. «С умным видом» это только вы тут пытаетесь рассуждать о вещах, о которых не имеете представления. Не надо, дураком себя выставляете.

Вообще совершенно не понятно зачем все эти сущности держать в голове. А если по-твоему и нужно...

Не нужно. Где я об этом писал?

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

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

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

И что? Это автоматически означает неприменимость паттерна Observer в Common Lisp? Почему?

И как быть с bordeaux-threads и имплементируемыми ими паттернами Bridge и Facade?

Это автоматически означает неприменимость

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

И, кстати, кто говорит про неприменимость?

Для тех кто не умеет читать

ну и хамло же ты недалёкое. ок, играйся дальше

Не дрочи на GoF, я же сказал уже.

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

lovesan

> Пруф?

Почитай Introduction к Design Patterns.

> ну и хамло же ты недалёкое

Лиспер же растет :)

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

Такую конструкцию с мета-синглтоном который собирает приложение как из кирпичей по топологии описанной в файле конфигурации можно собрать только по принципу позднего связывания. Я применяю позднее связывание для того чтобы порвать ненужные зависимости. Мой неупотребляющий вещества друг с неатрофированным мозгом tailgunner вообще всегда считал что позднее связывание не должно сужествовать.

> tailgunner вообще всегда считал что позднее связывание не должно сужествовать.

Лжешь. Ну, или галлюцинируешь %)

> Лиспер же растет :)

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

1) схема БД, 2) скелеты классов Java и С++, 3) маппинг для ORM, 4) документация

Понятно. Примитив. Ну да ладно, сам такой пишу :)

Проблему некоторых методов можно узреть, только продемонстрировав более эффективный метод. На словах продемонстрировать нельзя, так что наш спор обречен. Но я попробую. Далее конкретика:

Сможете за секунду распарсить, откуда класс наследуется, и с какими другими классами связан?

Смогу, конечно. Наберу в IDEA Ctrl + N, введу имя класса, сразу на классе Ctrl + F12. И вот передо мной сигнатура класса, с удобным поиском. Встречный вопрос, а сможете ли вы среди десятков полей и методов с похожими названиями быстро найти нужный? Я по первым буквам отыщу мгновенно. При этом все неясный моменты я могу уточнить еще и в коде. Вам же придется отрываться от своих диаграмм и где-то дополнительно искать. В общем в рисовании диаграмм есть только один изъян: при наличии удобной IDE, они просто избыточны. Не плохи, но избыточны.

Список в студию.

http://domaindrivendesign.org/resources/ddd_terms

+ очень нравятся паттерны из ФП: монады, функции (в жаве, например, функция - это паттерн) и так далее.

ddd

Перелез с одних баззвордов на другие?

> паттерны из ФП: монады, функции

От оно как, Михалыч...

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

Ты русишь язык понимать, йа?

Твой вопрос:

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

функциональных языках

функциональных

языках - даже множественное число.

> Ты русишь язык понимать, йа?

А ты? ТС действительно спрашивал о языках. А о хаскиговне не спрашивал.

Перелез с одних баззвордов на другие?

Ну а что, эволюция ведь.

> GoF - детсад, не стоит на них заострять внимание.

Двоичная арифметика - детсад. Стоит ли заосторять на ней внимание?

Стоит ли заосторять на ней внимание

Нет, не стоит. Ибо действительно детсад.

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

А потом плачемся «откуда же такие дебилушки взялись»..

Не возьмется же. Он же жавакодер, скалу возьмет скорее, чем хацкель.

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

Еще разок на всякий случай: не заострять внимание и не использовать - разные вещи.

Чтобы что-то использовать, нужно сначала об этом узнать. А чтобы что-то узнать, нужно заострить на этом своё внимание.

Всегда ваш, Кэп. ;)

После скалы рано или поздно прийдётся познакомиться и с хаскеллем.

Ну если ТС спрашивает про GoF-паттерны, то он уже наверное заострил, не? Ну разок то нужно, да.

>> tailgunner вообще всегда считал что позднее связывание не должно сужествовать.

Лжешь.

Ну допустим есть модули A и B. Теперь

а) Модуль А использует нечистую функцию foo из модуля B, чья нечистота обеспечивается глобальными переменными в модуле B. Если сингатура foo изменилась, ошибка возникнет при компиляции. По сути, B это синглтон.

б) У A есть connection point «foo». У B есть connection point «bar» с одинаковой сигнатурой. Эти две сущности связываются в рантайме при помощи чего-то типа рефлексии. Если сигнатура bar или foo изменилась, ошибка всплывет во время инициализации программы или даже позже если инициализация ленивая.

Я никогда не видел чтобы ты отстаивал вариант б.

Так еще раз - с чего ты взял «позднее связывание не должно сужествовать»?

> ну и хамло же ты недалёкое. ок, играйся дальше

пришёл в тред о лиспе
вбросил про хаскель
нахамил
красавчик :)

> Не дрочи на GoF, я же сказал уже.

Кто дрочит? Вы тут все как будто сублимируете на мне какие-то свои подсознательные страхи :)

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

Ну значит всё-таки получаются? Ты не замечаешь, а я вот замечаю. Это что, плохо?

>Так еще раз - с чего ты взял «позднее связывание не должно сужествовать»?

Твое отношение к динамической типизации известно. Позднее связывание в свою очередь делается именно при помощи оной.

> Почитай Introduction к Design Patterns.

Ткните меня в страницу и строку, где там содержится слово «костыль».

как всегда, в лисповый тред приходят хаскелляторы, и тред превращается, и превращается... в унылое гумно.

Ну значит всё-таки получаются? Ты не замечаешь, а я вот замечаю. Это что, плохо?

Важно разделять уровни.

1) У тебя есть задача, ты вспоминаешь, что в гофе для ее реализации есть определенный паттерн и тогда пишешь код.

2) У тебя есть проблема. Ты ее решаешь. А школоло из пункта 1. начинает замечать паттерны в готовой реализации.

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

> Понятно. Примитив. Ну да ладно, сам такой пишу :)

А что не примитив? Ковариантные функторы и коалгебра Келвина Элгота? Знаете, функторы и алгебры не летают в космос, не обеспечивают логистику и не обрабатывают транзакции. А я предпочитаю заниматься вещами, более-менее полезными для Человечества.

Смогу, конечно. Наберу в IDEA Ctrl + N, введу имя класса...

А, всё, я кажется понял. Для вас всё сводится к «поиску полей и методов». В этом случае IDE самый подходящий инструмент. Меня же интересуют не поля и методы, а сущности (классы) и разнообразные отношения между ними (некоторые из которых, такие как например extended dependency, не имеют своего отражения в коде).

А всё потому, что вы рассматриваете проблему как разработчик, а я - как архитектор.

> После скалы рано или поздно прийдётся познакомиться и с хаскеллем.

Кому «прийдётся»? Почему? На Скалу я уже поглядываю если что

> Твое отношение к динамической типизации известно. Позднее связывание в свою очередь делается именно при помощи оной.

Я уже говорил, что ты норкоман с атрофированным мозгом?

В общем господа, я сделал для себя выводы...

Большинство паттернов GoF вполне применимы к Common Lisp. Некоторые из Core J2EE Patterns тоже, например Application Controller.

Более того, многие используют их, самостоятельно открывая то, что было описано «бандой четырёх» в 1995 году и авторами Core J2EE Patterns в 1999-ом. Например, я уверен, что archimag в своём лисповом веб фреймворке переизобрёл тот же Application Controller. См. также вышеописанный пример с CL-GTK2 и паттерном Observer.

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

А если отбросить фанатизм и суеверия, то получится следующая простая суть. Code reuse и loose coupling - хорошо, т.к. способствуют extensibility и maintainability. Паттерны способствуют code reuse и loose coupling. Следовательно, паттерны - ... (каждый сделает вывод сам для себя)

> Знаете, функторы и алгебры не летают в космос, не обеспечивают логистику и не обрабатывают транзакции.

Боже, как ты ошибаешься! Ну, да черт с тобой :)

Меня же интересуют не поля и методы, а сущности (классы) и разнообразные отношения между ними

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

А всё потому, что вы рассматриваете проблему как разработчик, а я - как архитектор

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

>А я предпочитаю заниматься вещами, более-менее полезными для Человечества.

Ты даже не подозреваешь, как много ты о себе сказал этим одним предложением :D

Не дрочи на GoF. Ну нету смысла на них дрочить и пихать куда не попадя.

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

Например, у GoF есть разные «фабрики». В лиспе мы иногда думаем так - ага, ну вот, неплохо бы некоторую метаинформацию о классе хранить в самом объекте класса, а экземпляры класса создавать на ней основываясь. Мы в данном случае берем MOP, определяем метакласс, и переопределяем(специализируем) одну из ступеней в протоколе создания объектов(make-instance, allocate-instance, etc) для нашего класса, а может даже и для метакласса. Ну как-то так.

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

Короче, еще раз - не дрочи на GoF; дрочение на паттерны - нарушение принципа KISS.

lovesan

>Более того, многие используют их, самостоятельно открывая то, что было описано «бандой четырёх» в 1995 году и авторами Core J2EE Patterns в 1999-ом. Например, я уверен, что archimag в своём лисповом веб фреймворке переизобрёл тот же Application Controller. См. также вышеописанный пример с CL-GTK2 и паттерном Observer.

Не так. Есть языки в которых эти паттерны получаются сами собой и без каких-либо изобретений. Если бы банда четырех писала свои паттерны для ассемблера, то мы бы увидели такие паттерны как «функция». Однако вопрос применим ли паттерн функция в языке С++ вызывает лишь недоумение. Вот так.

> Боже, как ты ошибаешься!

Пруфы будут?

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

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

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

Неудивительно. Для пресмыкающихся по земле птичий полёт тоже кажется недостижимой «астронавтикой».

> Ты даже не подозреваешь, как много ты о себе сказал этим одним предложением :D

И что я такого о себе сказал этим одним предложением?

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

Не изволите ли продемонстрировать, каким образом в Common Lisp все 23 паттерна GoF и 23 паттерна J2EE «получаются сами собой»?

Что вы зациклились на мастурбации? Признание применимости паттернов в Common Lisp - это «дрочить»?

Давно здесь таких тролей не было.