Здравствуйте, WolfHound, Вы писали:
AVK>>Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией. Т.е. мы использовали паттерн. Или, если не синтетически, а аналитически, мы можем назвать использованное решение паттерном. WH>Еще один. Народ вам не надоело вызов одной функции назвать паттерном?
На вопрос ответ так и не получен. ЧТД.
WH>Такими темпами в паттерны можно записать буквально всё.
Можно. Но не нужно.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
WH>Они по тому и паттерны что их очень легко узнать. WH>А раз легко узнать значит, есть дублирование кода.
Если ты можешь узнать паттерн в коде это говорит о том что ты знаешь этот паттерн, и возможно это даже дублировании кода, но паттерн в этом не виноват, тем более паттерн проектирования. В этом виноват тот кто это написал. И очень даже может быть что написал он это потому что не знал этот паттерн(если-б знал возможно использовал бы готовое решение). WH>Архитекру делают под язык программирования, на котором будут писать код.
А если в проекте несколько языков?
И даже если и так, на этапе разработки архитектуры не известно каким будет код, даже в рамках одного языка(например будет ли он содержать классы или можно обойтись процедурами). WH>Ибо если ты попытаешься реализовать архитектуру, сделанную для явы на хаскеле или наоборот то у тебя получится такой кошмар что аж жуть.
Не знаю, не пробовал. WH>Таким образом классы итп появляются еще до того как начинают писать код.
Но после того как разработана архитектура, ибо это уже реализация. WH>Так они и есть копипаста и избыточный код.
Паттерн != код. WH>Вызов метода не паттерн. WH>Ибо иначе у нас вообще все становится паттерном. И весь разговор теряет смысл.
Паттерн это то что позволило программисту:
1)Опознать типичную проблему.
2)Найти реализацию решения.
3)"вызвать метод". WH>Ибо источник паттернов это несоответствие языка задаче.
От несоответствия ЯП задаче может появляется лишний код(адаптирующий), но уж всяко не паттерны проетирования. AC>>При создании DSL не будут использоваться паттерны? WH>Зачем? WH>Когда ты генерируешь код из ДСЛ можно генерировать что угодно.
Не ты не понял, при дизайне/разработке самого DSL'я? AC>>Подозреваю что ты представляеш себе разработку ПО как-то так: сделаем один DSL, поверх него ещё один, поверх второго третий,... последний DSL будет содержать единственный оператор "работай"? WH>Сарказм не получился.
Не, это был вопрос. WH>Ибо я так не только думаю. Но и делаю.
Чтобы использовать такой подход нужно уметь создавать DSL'и(а это сложно) что сводит на нет преимущество простоты их использования.
А если не использовать такой подход, а пользоваться готовыми языками то "привет "копипаста"!"
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AndrewVK, Вы писали:
WH>>Еще один. Народ вам не надоело вызов одной функции назвать паттерном? AVK>На вопрос ответ так и не получен. ЧТД.
На какой вопрос?
WH>>Такими темпами в паттерны можно записать буквально всё. AVK>Можно. Но не нужно.
Вот и не занимайся натягиванием слова паттерн на вызов одного метода.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexCab, Вы писали:
AC>Если ты можешь узнать паттерн в коде это говорит о том что ты знаешь этот паттерн, и возможно это даже дублировании кода, но паттерн в этом не виноват, тем более паттерн проектирования. В этом виноват тот кто это написал. И очень даже может быть что написал он это потому что не знал этот паттерн(если-б знал возможно использовал бы готовое решение).
Вот тебе обычный такой паттерн.
Встречается в определённом классе задач при решении на C#
private int _MyProp;
public int MyProp
{
get { retunr _MyProp; }
set
{
if (value != _MyProp)
{
_MyProp = value;
OnPropertyChanged("MyProp");
}
}
}
Узнается легко.
Встречается десятками и сотнями в одной программе.
Убрать дублирование средствами C# невозможно.
Средствами немерле сворачивается в одну строку.
public MyProp : int { get; set; }
Что фактически уничтожает паттерн.
Вот тебе еще примеры убирания лишнего кода. http://nemerle.org/wiki/index.php?title=Design_patterns
Да их там много.
AC>И даже если и так, на этапе разработки архитектуры не известно каким будет код, даже в рамках одного языка(например будет ли он содержать классы или можно обойтись процедурами).
Это не правда.
WH>>Ибо если ты попытаешься реализовать архитектуру, сделанную для явы на хаскеле или наоборот то у тебя получится такой кошмар что аж жуть. AC>Не знаю, не пробовал.
Вот попробуй. Узнаешь много нового.
WH>>Таким образом классы итп появляются еще до того как начинают писать код. AC>Но после того как разработана архитектура, ибо это уже реализация.
Так архитектура и задает реализацию.
Причем она всегда делается с учётом того на каком именно языке будет код.
AC>Паттерн это то что позволило программисту: AC>1)Опознать типичную проблему. AC>2)Найти реализацию решения. AC>3)"вызвать метод".
Ага, конечно.
Посмотри на код выше и вызови метод.
WH>>Ибо источник паттернов это несоответствие языка задаче. AC>От несоответствия ЯП задаче может появляется лишний код(адаптирующий), но уж всяко не паттерны проетирования.
Паттерны проектирования это и есть адаптация задачи к языку.
Ты, например, использовал зиппер и scrap your boilerplate?
А вот программисты на хаскеле не использовали визитер с абстрактными фабриками.
AC>Не ты не понял, при дизайне/разработке самого DSL'я?
Зачем?
У меня для этого ДСЛ есть.
AC>Чтобы использовать такой подход нужно уметь создавать DSL'и(а это сложно) что сводит на нет преимущество простоты их использования.
Это проще чем ООП дизайн делать.
И использовать их проще.
AC>А если не использовать такой подход, а пользоваться готовыми языками то "привет "копипаста"!"
О чем я и говорю.
Вы все копипастите на ровном месте.
И называете это красивым словом паттерн.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ГВ>>Хотя я не спорю, что в мире полно наивных программистов, которые так же наивно "пихают паттерны" куда угодно, а потом ищут глубокий смысл в постановке вещей с ног на голову. Но не надо делать далеко идущих выводов из чужих глупостей, ага? WH>Готов спорить, что в твоем коде полно паттернов. WH>Просто по тому, что ты пишешь на языке общего назначения. WH>А он про твою предметную область ничего не знает.
Прикольно. Я тебе про Фому, ты мне — про Ерёму.
WH>Вот, например берем вот такой интерфейс WH>http://msdn.microsoft.com/en-us/library/system.componentmodel.inotifypropertychanged.aspx WH>Его реализация одинакова до безобразия. WH>И ни какими средствами C# ты ее не автоматизируешь.
WH>Те у тебя в коде будет повторяющейся паттерн.
[...] WH>Вот это я называю паттернами и борьбой с ними.
Ясно, но, ИМХО, это довольно узкая интерпретация, по такой логике обычные библиотеки тоже можно назвать борцами с паттернами, хотя почему-то я таких названий не встречал. По сути, как это правильно сказал Игорь, ты никуда не деваешь сам паттерн, ты просто вносишь его частную реализацию в библиотеку. Так что, не обольщайся — например, для разбора того, что же делает твой макрос, будет снова использоваться описание паттерна.
Я называю паттернами более широкую группу явлений. Повторю свой пример:
class X {
public void foo(); // Фасадpublic void zoo(); // Фасадprotected void bar(); // Реализация
}
В данном случае нигде в коде, кроме комментариев и, возможно, сопроводительной документации не будет фигурировать термин "фасад". Просто появится соглашение, что foo и zoo — фасадные методы. Допустим, их не будут менять слишком бодро при очередном рефакторинге и т.п. И никакого лишнего кода. В конце концов, главное — это та информация, которая передана людям.
Я вполне согласен, что, может быть, имеет смысл сделать как-нибудь так:
[FacadeMethods(foo, zoo)]
class X {
void foo();
void zoo();
void bar();
}
Правда, одно не понятно: а на фига?
ГВ>>Правильно, только обрати внимание, ты сейчас соскальзываешь с паттернов на задачу реализации терминов предметной области. Я же тебе говорю, не уподобляйся идиотам — не смешивай разные по сути явления. WH>Паттерн возникает при реализации задачи предметной области на языке, который на эту предметную область не заточен. WH>См пример выше.
O'K, примем это высказывание как пояснение к твоему определению паттерна.
ГВ>>Пробовал, впечатления равноценны тем, что возникают, когда бесконечно совершенствуешь библиотеку. WH>Извини, не поверю. WH>Просто все те, кто действительно этим занимался в реальных задачах, назад не хотят.
Ещё бы ты согласился! По сути ты сейчас рассуждаешь как фанатик — коверкаешь устоявшиеся термины и определения, бросаешься обобщениями ("все они такие"). А от фаната бессмысленно ждать согласия с чем-то таким, что противоречит его убеждениям.
ГВ>>(Гы-гы, сейчас начнут говорить, что у меня дзен неправильный и дао не туда) WH>Ну, так продемонстрируй свой дзен. WH>Только не говори что ты это на С++ных шаблонах делал. WH>Сразу засмею.
Я его и продемонстрировал, а ты не заметил. Так что, тебе надо продолжать практиковаться в дзен. Мне-то твой дзен понятен...
WH>>>Ибо если язык позволяет вводить новые конструкции, то они автоматически становятся библиотеками. ГВ>>Правильно. И так же автоматически перестают быть паттернами, становясь библиотеками. Забавная трансформация, правда? WH>Так они именно за тем и вводятся, чтобы убить паттерны.
Да не "убить паттерны", а забить в библиотеку их частные реализации. Всё, что здесь уничтожается — это дублирование кода. А паттерны, как обощённые структурные модели, остаются живёхоньки.
WH>См пример выше. WH>Просто обычные библиотеки не могут убить паттерн. А языковые расширения могут. WH>Причем если при их использовании снова возникает паттерн мы можем повторить итерацию еще раз.
Приходим к противоречию.
Если следовать твоей логике, что "паттерн — это повторяющаяся часть кода", то библиотеки — такое же средство "борьбы с паттернами", как и новый язык. Пусть не такое мощное, поскольку ограничено самим языком, но тем не менее.
А если опереться на общепринятое определение, что паттерн — это надъязыковая модель, то придётся констатировать, что ни библиотеки, ни новый язык не могут "убить паттерн", поскольку они его попросту реализуют, но никуда при этом не удаляют. Паттерн по-прежнему остаётся в описаниях и в языке общения разработчиков.
ГВ>>Во-первых, я знаю как минимум ещё один вариант появления копипасты — сознательное сохранение простоты кода. ГВ>>Во-вторых, паттерны — это не всегда копипаста. WH>Вот то, что выше это не копипаста да? И все паттерны они такие.
То, что ты ими называешь — да. Правда, почему-то, твоё мнение разделяют не все.
WH>Паттерн он на то и паттерн что глядя на два куска кода видишь насколько они одинаковые. WH>Но сделать с этим ничего не можешь. WH>Ибо язык не позволяет.
Ну почему же сразу "не позволяет"? Чаще дело сводится к тому, что нет нужды заниматься реализацией обобщённого решения, гораздо проще и легче сделать "копипасту" (ещё одна крамольность), чем выдумывать новые имена для того, что не нужно именовать. Я не всегда согласен с Ikemefula, но в данном случае наши мнения практически совпадают.
ГВ>>Куча одинаковых визитеров, фабрик и т.п. — это нюансы реализаций. И что самое весёлое, что ровно та же куча одинаковых реализаций схожих, но уже языковых конструкций будет появляться в разных фирмах (или вообще — у разных программистов). И всё это будет происходить только из-за того, что источники изменений будут разрознены, т.е. ровно из-за того, из-за чего появляется разнобой в библиотеках. WH>Разнобой вообще оффтопик.
Хорошо, пусть так.
ГВ>>Скажи, будь добр, новая языковая конструкция будет ориентирована на конкретные типы данных и другие подобные конструкции, пусть даже описательного характера? Или она зависнет на воздусех и "сама" будет привязываться ко всему, чему угодно? WH>А как реализуешь, так и будет. WH>Отчет практика.
Кроме того у Nemerle есть свой match/биндинг по регекспам (называется кажется rx match или regex match), и мы по образу и подобию слепили себе такой же, но почему и чем он был лучше — уже не помню.
P.P.S.: И с вот таким паттерном как быть: "Интерфейс"?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Прикольно. Я тебе про Фому, ты мне — про Ерёму.
Я тебе про сущность понятия паттерн.
ГВ>Ясно, но, ИМХО, это довольно узкая интерпретация, по такой логике обычные библиотеки тоже можно назвать борцами с паттернами,
Совершенно верно.
Они и есть борцы с паттернами также известными как копипаста.
ГВ>хотя почему-то я таких названий не встречал.
Это по тому, что те паттерны, с которыми успешно борются, исчезают из кода.
Нет паттерна. Нет обсуждения.
Но не все паттерны могут устранить библиотеки для обычных языков.
Вот те паттерны, которые не могут быть устранены, начали изучаться и классифицироваться.
Но это не отменяет то, что они копипаста.
И более мощные языки это наглядно доказывают.
ГВ>По сути, как это правильно сказал Игорь, ты никуда не деваешь сам паттерн, ты просто вносишь его частную реализацию в библиотеку. Так что, не обольщайся — например, для разбора того, что же делает твой макрос, будет снова использоваться описание паттерна.
А всегда говорил про код.
И код исчез.
А уж что там сгенерирует компилятор дело десятое.
ГВ>В данном случае нигде в коде, кроме комментариев и, возможно, сопроводительной документации не будет фигурировать термин "фасад". Просто появится соглашение, что foo и zoo — фасадные методы. Допустим, их не будут менять слишком бодро при очередном рефакторинге и т.п. И никакого лишнего кода. В конце концов, главное — это та информация, которая передана людям.
Тут нет задачи.
Обсуждать борьбу с паттернами без исходной не замутненной реализацией задачи не имеет смысла.
Никакого.
И что касается этого твоего фасада, то я вообще не помню, чтобы хоть раз применял что-то похожее.
ГВ>Я его и продемонстрировал, а ты не заметил. Так что, тебе надо продолжать практиковаться в дзен. Мне-то твой дзен понятен...
Ну да. Узнаю твой типичный паттерн поведения.
Слив -> демагогия.
Очень типично для тебя.
ГВ>Да не "убить паттерны", а забить в библиотеку их частные реализации. Всё, что здесь уничтожается — это дублирование кода. А паттерны, как обощённые структурные модели, остаются живёхоньки.
Не остаются.
Ибо они исчезают из кода.
И распознать их уже нельзя.
А во что их превращает компилятор уже не важно.
WH>>См пример выше. WH>>Просто обычные библиотеки не могут убить паттерн. А языковые расширения могут. WH>>Причем если при их использовании снова возникает паттерн мы можем повторить итерацию еще раз. ГВ>Приходим к противоречию.
В каком месте?
ГВ>Если следовать твоей логике, что "паттерн — это повторяющаяся часть кода", то библиотеки — такое же средство "борьбы с паттернами", как и новый язык. Пусть не такое мощное, поскольку ограничено самим языком, но тем не менее.
Ну да. Библиотеки борются с некоторым очень примитивным классом паттернов.
Но их обсуждать не имеет смысла.
Ибо если программист грамотный, то их в коде и так не будет.
ГВ>А если опереться на общепринятое определение, что паттерн — это надъязыковая модель, то придётся констатировать, что ни библиотеки, ни новый язык не могут "убить паттерн", поскольку они его попросту реализуют, но никуда при этом не удаляют. Паттерн по-прежнему остаётся в описаниях и в языке общения разработчиков.
Начнем с того что паттерны прибиты гвоздями к группе похожих с семантической точки зрения языков.
На этом и закончим.
Ибо это делает всю твою цепочку рассуждений ложной.
ГВ>То, что ты ими называешь — да. Правда, почему-то, твоё мнение разделяют не все.
Просто не хотят признавать что нанимаются копипастой.
Но признание проблемы это первый шаг к ее исправлению.
ГВ>Ну почему же сразу "не позволяет"? Чаще дело сводится к тому, что нет нужды заниматься реализацией обобщённого решения, гораздо проще и легче сделать "копипасту"
Ну, реализуй мне на C# обобщенное решение для INotifyPropertyChanged.
Удачи.
А потребность есть.
Ибо народ даже переписыванием IL занимается, чтобы этот код не писать.
ГВ>(ещё одна крамольность), чем выдумывать новые имена для того, что не нужно именовать. Я не всегда согласен с Ikemefula, но в данном случае наши мнения практически совпадают.
Вот только ни ты, ни он не показали, что же не нужно именовать.
И чему при создании ДСЛ придется дать имя.
ГВ>
Кроме того у Nemerle есть свой match/биндинг по регекспам (называется кажется rx match или regex match), и мы по образу и подобию слепили себе такой же, но почему и чем он был лучше — уже не помню.
ГВ>Извини, я не удержался.
И что? У них была проблема. Они ее решили. Был бы C# они бы трахались неизмеримо сильнее.
Или ты хочешь сказать, что ни разу в жизни не выкидывал стандартную библиотеку по тому, что она тебя не устраивала?
Короче прекращай разводить двойные стандарты.
ГВ>P.S.: Кстати, а как по твоему методу можно изничтожить паттерн "Chain of responsibilities"?
Без исходной задачи не имею ни малейшего представления.
ГВ>P.P.S.: И с вот таким паттерном как быть: "Интерфейс"?
Ты еще вызов метода как это делают AVK и Ikemefula в паттерны запиши.
В любом случае, когда дело доходит до конкретной задачи оказывается что и это не нужно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Т.е. ты даже не читал то, на что ответил? AVK>
AVK>>Теперь вопрос — как в описанной цепочке DSL помогут куда то там деть паттерн?
Где паттерн то?
У тебя там вызов ровно одной функции который один документ превращает в коллекцию других.
AVK>Попробуй найти в моем описании задачи фразу "вызов одного метода", или хотя бы слово "метод".
Метод. Функция. Не важно.
Главное что у тебя только один вызов. А уже целый паттерн.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Вот тебе обычный такой паттерн. WH>Встречается в определённом классе задач при решении на C# WH>
WH> private int _MyProp;
WH> public int MyProp
WH> {
WH> get { retunr _MyProp; }
WH> set
WH> {
WH> if (value != _MyProp)
WH> {
WH> _MyProp = value;
WH> OnPropertyChanged("MyProp");
WH> }
WH> }
WH> }
WH>
WH>Узнается легко. WH>Встречается десятками и сотнями в одной программе.
1)Это не паттерн проектирования, ПП выглядит примерно так:
2)Это вообще не паттерн это частный случай реализации. WH>Убрать дублирование средствами C# невозможно.
На C# я никогда не писал, но думаю это можно заменить классической парой методов get/set. WH>Средствами немерле сворачивается в одну строку. WH>
WH>public MyProp : int { get; set; }
WH>
Что фактически уничтожает паттерн.
А где тела get'а и set'а? WH>Вот тебе еще примеры убирания лишнего кода. WH>http://nemerle.org/wiki/index.php?title=Design_patterns
Я верю что ты можешь спрятать любую реализацию паттерна в макрос/DSL, ибо МП даёт полую власть над текстом программы(требуя в замен полной ответственности). AC>>И даже если и так, на этапе разработки архитектуры не известно каким будет код, даже в рамках одного языка(например будет ли он содержать классы или можно обойтись процедурами). WH>Это не правда.
Почему? AC>>Но после того как разработана архитектура, ибо это уже реализация. WH>Так архитектура и задает реализацию.
Но не является её. WH>Причем она всегда делается с учётом того на каком именно языке будет код.
Но не более. AC>>Паттерн это то что позволило программисту: AC>>1)Опознать типичную проблему. AC>>2)Найти реализацию решения. AC>>3)"вызвать метод". WH>Ага, конечно. WH>Посмотри на код выше и вызови метод.
Элементарно:
1)берём Немерле, или какой ни будь препроцессор для C#, прячем реализацию в макрос, вызываем.
2)меняем все подобные вещи на пары get/set методов, вызываем. AC>>От несоответствия ЯП задаче может появляется лишний код(адаптирующий), но уж всяко не паттерны проетирования. WH>Паттерны проектирования это и есть адаптация задачи к языку.
Наверно всё-таки языка (общего н.) к задаче.
Но это всё гораздо менее интересно чем следующее:
AC>>Не ты не понял, при дизайне/разработке самого DSL'я? WH>Зачем? WH>У меня для этого ДСЛ есть.
DSL-дизайнер, DSL-архитектор — интригует
Если DSL'и не дизайнятся и не разрабатываются, откуда они берутся?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>1)Это не паттерн проектирования, ПП выглядит примерно так: AC> AC>2)Это вообще не паттерн это частный случай реализации. Это паттерн просто по определению паттерна. Значение слова паттерн посмотри.
WH>>Убрать дублирование средствами C# невозможно. AC>На C# я никогда не писал, но думаю это можно заменить классической парой методов get/set.
Это и есть пара методов get/set.
Но даже если написать методы явно, то гора копипаста всё равно не пропадет. Её станет еще больше.
WH>>Средствами немерле сворачивается в одну строку. WH>>
WH>>public MyProp : int { get; set; }
WH>>
Что фактически уничтожает паттерн. AC>А где тела get'а и set'а?
Нету. Их макрос генерирует.
Вместе с полем и вызовом OnPropertyChanged("MyProp");
WH>>Вот тебе еще примеры убирания лишнего кода. WH>>http://nemerle.org/wiki/index.php?title=Design_patterns AC>Я верю что ты можешь спрятать любую реализацию паттерна в макрос/DSL, ибо МП даёт полую власть над текстом программы(требуя в замен полной ответственности).
Не спрятать. Уничтожить.
Ибо в коде повторения больше нет.
AC>>>И даже если и так, на этапе разработки архитектуры не известно каким будет код, даже в рамках одного языка(например будет ли он содержать классы или можно обойтись процедурами). WH>>Это не правда. AC>Почему?
Я уже раз 100 говорил, что архитектура делается под язык. Максимум под группу очень сильно похожих языков типа C# и Java. Но даже тут всё не просто ибо их инфраструктура очень разная.
WH>>Посмотри на код выше и вызови метод. AC>1)берём Немерле, или какой ни будь препроцессор для C#, прячем реализацию в макрос, вызываем. AC>2)меняем все подобные вещи на пары get/set методов, вызываем.
Это уже будет изменение языка.
А ты без изменения C# сделай.
WH>>Паттерны проектирования это и есть адаптация задачи к языку. AC>Наверно всё-таки языка (общего н.) к задаче.
Нет. Именно задача натягивается на язык.
Ибо языки, в коде которых обнаружились данные паттерны, просто не могут изменить себя под задачу.
AC>>>Не ты не понял, при дизайне/разработке самого DSL'я? WH>>Зачем? WH>>У меня для этого ДСЛ есть. AC>DSL-дизайнер, DSL-архитектор — интригует AC>Если DSL'и не дизайнятся и не разрабатываются, откуда они берутся?
И нахрена ДСЛю архитектура?
Для ДСЛ важны сущности и отношения между сущностями.
Всё остальное не важно.
Тот код, в который они превращаются, всё равно никто не читает. Так что и усилий к тому чтобы сделать его понятным человеку прилагать не нужно.
Можно генерировать говнокод как попало. Главное чтобы работал. Ну, максимум о чем можно побеспокоиться, чтобы он быстро работал и мало памяти кушал.
И что характерно эти требования входят в конфликт с требованием, чтобы код был понятен людям.
А в случае с ДСЛ такого конфликта нет. Ибо требования понятности людям генерируемого кода нет. Более того ДСЛ позволяет производить оптимизации на высоком уровне и добиваться такой эффективности что руками просто не сделать. В ошибках утонешь.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>У тебя там вызов ровно одной функции который один документ превращает в коллекцию других.
Ты не оттуда пляшешь. Вызов функции это уже не паттерн, это его вопрощение в конкретный код. И в реальности это далеко не просто вызов одной функции, это целый объект, причем персистентный, с несколькими методами. Паттерн не диктует конкретный код, это не копипаста.
AVK>>Попробуй найти в моем описании задачи фразу "вызов одного метода", или хотя бы слово "метод". WH>Метод. Функция. Не важно.
Важно. Потому что слово "функция" тут применено в математическом смысле, а не в программном.
WH>Главное что у тебя только один вызов.
Нет. Ты упорно не хочешь видеть разницу между проектом и кодом.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Игoрь, Вы писали:
И>>Это не паттерн, а его реализация. Скажу больше, это одна из возможных реализаций Наблюдателя. WH>Ох. Что такое паттерн. WH>Паттерн это нечто повторяющееся. WH>Например, посмотри в гугле картинки по слову pattern. WH>Увидишь много картинок, на которых повторяется что-то.
Я правильно тебя понимаю, что твое знакомство с паттернами ограничивается каринками в гугле? Причем искал ты не по software design patterns, а просто по patterns? Это объясняет...
Давай кроме картинок еще и боковки почитаем. Итак, первая ссылка на вики:
Software design pattern
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Patterns are formalized best practices that the programmer must implement themselves in the application. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.
И>>А это реализация того же самого паттерна, но на другом языке. WH>Тут нет паттерна. WH>Вот эта хрень не повторяется. И>>Где борьба то? Паттерн как был, так и остался. WH>Как это остался? WH>Где повторение вон той хрени чуть выше по тексту?
Повторение есть на уровне "задача-решение". То, что у тебя в коде могут встречаться похожие куски — это еще не делает эти куски кода паттерном. Повторение будет, когда у тебя возникнет похожая задача и ты реализуешь MyClass1, MyClass2.
И>>Чем характеризуется паттерн? Задачей и ее решением. WH>Нет. Он характеризуется повторяющимся кодом. WH>Ты извращаешь понятие паттерн. WH>Паттерн это не решение. Это распознаватель решения.
Читай до просветления:
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
Здравствуйте, WolfHound, Вы писали:
WH>Для ДСЛ важны сущности и отношения между сущностями.
Это и есть архитектура. По определению.
The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
(С) Википедия.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
WH> Это паттерн просто по определению паттерна. Значение слова паттерн посмотри.
Ok, смотрим 1,2,3
Ни в одной, ни строчки кода. WH>Это и есть пара методов get/set. WH>Но даже если написать методы явно, то гора копипаста всё равно не пропадет. Её станет еще больше.
Да. AC>>А где тела get'а и set'а? WH>Нету. Их макрос генерирует. WH>Вместе с полем и вызовом OnPropertyChanged("MyProp");
Т.е. ты их спрятал в макрос? AC>>Я верю что ты можешь спрятать любую реализацию паттерна в макрос/DSL, ибо МП даёт полую власть над текстом программы(требуя в замен полной ответственности). WH>Не спрятать. Уничтожить. WH>Ибо в коде повторения больше нет.
Ok, ты уничтожишь повторения, но ведь не паттерн(см. выше определение слова "паттерн"). WH>Я уже раз 100 говорил, что архитектура делается под язык. Максимум под группу очень сильно похожих языков типа C# и Java. Но даже тут всё не просто ибо их инфраструктура очень разная.
А как насчёт проектов в которых например есть Python(для описания логики), C(для критических по производительности), Erlang(для распределения), Java(для сервисной части)? WH>Это уже будет изменение языка. WH>А ты без изменения C# сделай.
Я и не говорил что ограничений языков(заставляющих заниматься копипастой или избыточным кодированием) не существует, но причём здесь паттерны проектирования? WH>>>Паттерны проектирования это и есть адаптация задачи к языку. AC>>Наверно всё-таки языка (общего н.) к задаче. WH>Нет. Именно задача натягивается на язык.
ИМХО, ты смотришь на проблему не стой стороны(со стороны ЯП, а не со стороны задачи), ну да тебе видней. WH>Ибо языки, в коде которых обнаружились данные паттерны, просто не могут изменить себя под задачу.
Наверно всё-таки "языки, в коде которых обнаружилось дублирование кода"?
AC>>Если DSL'и не дизайнятся и не разрабатываются, откуда они берутся? WH>И нахрена ДСЛю архитектура?
По моему скромному мнению DSL состоит как минимум из:
1)Синтаксиса, которой требует дизайна и разработки(чтобы быть эргономичным и логичным).
2)Транслятора(не важно как реализованного, на макросах или на Pythone'е), которой требует дизайна и разработки(чтобы быть быстрым и удобным).
3)Семантики(то что генерирует транслятор), которая требует дизайна и разработки(чтобы быть быстрой, безошибочной и интегрируемой). WH>Для ДСЛ важны сущности и отношения между сущностями. WH>Всё остальное не важно.
Подозреваю что ты конструируешь DSL'и методом добавления фичь по ходу работы? WH>Можно генерировать говнокод как попало. WH>Тот код, в который они превращаются, всё равно никто не читает.
Это до первой серьёзной ошибки в нижних DSL'ях (слоях абстракции).
Или до первого рефакторинга дерева DSL'ей.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты не оттуда пляшешь. Вызов функции это уже не паттерн, это его вопрощение в конкретный код. И в реальности это далеко не просто вызов одной функции, это целый объект, причем персистентный, с несколькими методами. Паттерн не диктует конкретный код, это не копипаста.
Ну, так это по тому, что ты всё видишь через призму C#.
А если посмотреть на чистую задачу, то от всего этого останется одна функция.
AVK>Важно. Потому что слово "функция" тут применено в математическом смысле, а не в программном.
А разве есть разница?
У нас в предметной области вполне себе математическая функция.
Значит и в коде должна быть математическая функция.
И ничего больше.
Всё остальное должен генерировать компилятор.
AVK>Нет. Ты упорно не хочешь видеть разницу между проектом и кодом.
Я упорно не хочу видеть тот код, который ты колбасишь ручками по паттернам.
Я хочу, чтобы этот код колбасил компилятор. Причем так чтобы этот код вообще ни кто не видел.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Игoрь, Вы писали:
И>Я правильно тебя понимаю, что твое знакомство с паттернами ограничивается каринками в гугле?
Нет. Но тебе стоит почитать определение слова паттерн. И посмотреть на картинки.
И> Причем искал ты не по software design patterns, а просто по patterns? Это объясняет... И>Давай кроме картинок еще и боковки почитаем. Итак, первая ссылка на вики:
Ох. http://nemerle.org/wiki/index.php?title=Design_patterns
Там наглядна видна копипаста которую порождают паттерны.
И как она исчезает. При использовании макроса.
И>Повторение есть на уровне "задача-решение". То, что у тебя в коде могут встречаться похожие куски — это еще не делает эти куски кода паттерном.
Это именно что сделает это паттерном.
Просто по определению паттерна.
Просто те паттерны о которых ты говоришь встречаются так часто что их даже классифицировали.
А всё из-за слабости языков программирования.
WH>>Паттерн это не решение. Это распознаватель решения. И>Читай до просветления:
Лучше ты сходи почитай определение слово паттерн.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
WH>>Для ДСЛ важны сущности и отношения между сущностями. AVK>Это и есть архитектура. По определению. AVK>
AVK>The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.
AVK>(С) Википедия.
Так я и говорю что ДСЛ и есть архитектура.
А ты тут со мной споришь.
И как только у нас появляется ДСЛ точно отражающий предметную область архитектура готова.
Можно спокойно сажать прикладников писать бизнеслогику. Они ничего не сломают. Им ДСЛ не позволит.
После чего можно спокойно заняться оптимизацией того кода который генерирует ДСЛ.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexCab, Вы писали:
AC>А как насчёт проектов в которых например есть Python(для описания логики), C(для критических по производительности), Erlang(для распределения), Java(для сервисной части)?
В том-то и дело, ни один из этих языков не подходит для решения всех классов задач. В том-то и дело, что применение языка с метапрограммированием, наподобие Nemerle, позволяет избавиться от кучи разных языков. На N пишутся DSL'и, которые будут идеальны для логики, для производительности. для распреледения и всего прочего.
AC>ИМХО, ты смотришь на проблему не стой стороны(со стороны ЯП, а не со стороны задачи), ну да тебе видней.
Хм, по-моему WolfHound постоянно твердит, что именно со стороны задачи нужно смотреть! И только DSL позволяют это делать. А применение ЯОН — это как раз взгляд со стороны ЯП.
AC>По моему скромному мнению DSL состоит как минимум из: AC>1)Синтаксиса, которой требует дизайна и разработки(чтобы быть эргономичным и логичным).
Его не нужно изобретать: берём термины предметной области, и всё!
AC>2)Транслятора(не важно как реализованного, на макросах или на Pythone'е), которой требует дизайна и разработки(чтобы быть быстрым и удобным).
Nemerle — готовый транслятор. N2, по замыслам разрабов, будет ещё удобней.
AC>3)Семантики(то что генерирует транслятор), которая требует дизайна и разработки(чтобы быть быстрой, безошибочной и интегрируемой).
Ну, тут по моему разумению будет примерно то же, что и при написании обычных библиотек. Только потом можно будет пользоваться удобной терминологией предметной области, а не функции, натянутые на глобус, вызывать.
Здравствуйте, AlexCab, Вы писали:
WH>> Это паттерн просто по определению паттерна. Значение слова паттерн посмотри. AC>Ok, смотрим
Я говорю про значение слова паттерн вообще.
Поинтересуйся откуда это слово вообще взялось.
WH>>Нету. Их макрос генерирует. WH>>Вместе с полем и вызовом OnPropertyChanged("MyProp"); AC>Т.е. ты их спрятал в макрос?
Я их убрал из кода.
Теперь в коде только то, что имеет значение.
И никакого мусора.
Паттерна больше нет.
AC>Ok, ты уничтожишь повторения, но ведь не паттерн(см. выше определение слова "паттерн").
Паттерн это и есть повторения. Просто по определению.
pattern
a particular way in which something is done, organized or happens
The pattern of family life has been changing over recent years.
A pattern is beginning to emerge from our analysis of the accident data.
In this type of mental illness, the usual pattern is bouts of depression alternating with elation.
Many behaviour(al) patterns have been identified in the chimp colony.
any regularly repeated arrangement, especially a design made from repeated lines, shapes or colours on a surface
Look, the frost has made a beautiful pattern on the window.
I've never really cared for floral patterns.
something which is used as an example, especially to copy
The design is so good it's sure to set the pattern for many others.
a drawing or shape used to show how to make something
a knitting pattern
a dress pattern
Cut out all of the pieces from the paper pattern and pin them on the cloth.
a small piece of cloth or paper taken from a usual-sized piece and used to show what it looks like; a sample
a pattern book
AC>А как насчёт проектов в которых например есть Python(для описания логики), C(для критических по производительности), Erlang(для распределения), Java(для сервисной части)?
И что? Ну, разделили проект на части.
И каждую часть отархитектурили под конкретный язык.
AC>Я и не говорил что ограничений языков(заставляющих заниматься копипастой или избыточным кодированием) не существует, но причём здесь паттерны проектирования?
При том, что они и есть формализованная копипаста.
Несмотря на все красивые слова, реализация паттернов повторяется практически 1 в 1 из проекта в проект.
Копипаста как она есть.
AC>ИМХО, ты смотришь на проблему не стой стороны(со стороны ЯП, а не со стороны задачи), ну да тебе видней.
Нет. Именно что со стороны задачи.
И мне больно видеть, как её бедную извращают, чтобы натянуть на язык.
Вместо того чтобы сделать по нее язык и не заниматься фигней.
WH>>Ибо языки, в коде которых обнаружились данные паттерны, просто не могут изменить себя под задачу. AC>Наверно всё-таки "языки, в коде которых обнаружилось дублирование кода"?
Это и есть паттерн.
Все паттерны обнаружились, когда люди смотрели на код и видели что делают раз за разом одно и то же.
Те авторы Design Patterns: Elements of Reusable Object-Oriented Software сначала перелопатили кучу готового кода.
Нашли кучу повторяющихся кусков кода.
Классифицировали их и дали им имена.
WH>>Для ДСЛ важны сущности и отношения между сущностями. WH>>Всё остальное не важно. AC>Подозреваю что ты конструируешь DSL'и методом добавления фичь по ходу работы?
Ты так говоришь как будто это что-то плохое.
Видишь ли, в чем дело. Когда делаешь ДСЛ можно себе такое позволить.
Знаешь почему?
А по тому, что я могу поменять один раз генератор и перекомпилировать весь код.
Это дает мне возможность десятком строк безошибочно протащить что-то черед мегабайты генеренного кода.
А те, кто это код пишут руками, так не могут.
Вот и страдают с архитектурой.
И всё равно всегда не угадывают.
И архитектура сползает в говно под гнетом изменяющихся требований.
AC>Это до первой серьёзной ошибки в нижних DSL'ях (слоях абстракции). AC>Или до первого рефакторинга дерева DSL'ей.
Раз в год. А код на ДСЛ, который в 10-100 раз меньше будет писаться, и читаться постоянно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Ну, так это по тому, что ты всё видишь через призму C#.
Ты, мне кажется, с какими то своими иллюзиями споришь. Где я хоть раз упомянул C#?
AVK>>Важно. Потому что слово "функция" тут применено в математическом смысле, а не в программном. WH>А разве есть разница?
Есть.
WH>У нас в предметной области вполне себе математическая функция. WH>Значит и в коде должна быть математическая функция.
Не обязательно. И, главное, паттерн Стратегия ничего подобного не диктует. Ты сам обвешиваешь паттерны каким то лишним для них смыслом, и потом сам себя и опровергаешь. Тебе уже несколько человек по нескольку раз повторили — паттерн это не шаблонный код, это шаблонный элемент дизайна. Если возможности языка позволяют реализацию паттерна написать один раз — отлично. Но паттерна это никоим образом не отменяет. Например, от того что в шарпе есть ключевое слово event паттерн Publisher-Subscriber никуда не девается, его просто не надо описывать многословно.
WH>Всё остальное должен генерировать компилятор.
Архитектуру решения пока что ни один компилятор генерировать не умеет. Даже компилятор Немерле.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Это паттерн просто по определению паттерна. Значение слова паттерн посмотри.
