Здравствуйте, Sinclair, Вы писали:
S>В одном случае вообще нет требования выбора разных способов генерации проводок в рантайме. S>В другом случае есть один алгоритм с дополнительными параметрами. S>В твоём случае есть семейство разных алгоритмов с ручным выбором конкретного.
Требование одно — обеспечить покрытие конкретных потребностей разных предприятий одним продуктом. Коробка — конкретного клиента нет.
S>>>В таком описании для проектирования достаточно трёх паттернов: Стратегия (она же Policy), Следование (она же Последовательность), и Ничто. AVK>>Поясни мысль. S>Поясняю: это базис, из которого можно построить всё остальное. операторы if, приращения, и 0.
И что? При чем тут операторы if? Я еще раз напомню определение паттерна — это слово в словаре для описания архитектуры.
S>А можно продемонстрировать как-то способ применения паттерна Стратегия в терминах таблиц и прочих сущностей SQL?
Можно.
declare @alg varchar;
select @alg=alg
from algs
where doctype = (select type from docs where id=@docid);
execute sp_executesql @alg, @docid;
AVK>>Этот вопрос в топике уже был — на какие нижележащие концепции опирается паттерн Chain of Resposibility? MVC? S>На ООП, очевидно.
Т.е. уже не на концепции языка, а на концепции целого класса языков. И именно ООП — не обязательно. Достаточно наличия в языке понятия сущности. В ФП, к примеру, кортеж функций прекрасно справится с MVC.
S>При применении DSL код программы совпадает с её архитектурой.
В идеале. Но это означает прямо противоположное — программа на DSL целиком из архитектуры состоит, а вовсе не отменяет ее. И я это с самого начала говорил.
AVK>>А никто тут ничего подобного и не говорит. Если соответствовать приведенному определению паттерна, то "континентальный завтрак" это термин, который нужен чтобы написать его в меню, и клиенты по нему сразу поймут, о чем речь, не вдаваясь в детальное изучение всех ингредиентов и способов их приготовления. S>Правильно. И тем не менее, это определённое решение определённой задачи.
Решение концептуальное ака архитектура. А решение конкретное ака код это рецепты приготовления континентального завтрака. И даже если мы вместо повара ака программиста заведем автоматическую машину с кнопкой "приготовить континентальный завтрак" ака DSL, термин "континентальный завтрак" из меню никуда не денется.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
VD>Очень подходящее описание для функции возвращающей функцию
Шиворот навыворот. Это указатель на функцию это подходящая реализация для стратегии в том случае, когда стратегию можно описать одной функцией. Если нельзя — реализации будут либо объектами с несколькими методами, либо кортежом функций.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, VladD2, Вы писали:
VD>До суда все понятно.
А после суда паттерны уже не нужны, код писать надо.
VD>Скажу больше. Твои слова "документ" и "ХО" уже говорят о том, что ты оперируешь не предметной областью, аз знакомым тебе алгоритмом (подходом).
Я описываю конкретный дизайн. Не задачу, а дизайн, понимаешь? Готовый.
VD>В моем решении документ и ХО могут быть единым целым
И это другой дизайн.
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
WH>>>Двойные стандарты на марше. Какая прелесть. ГВ>>Где ты их увидел? WH>Майкрософту можно. Мне нельзя.
Почему это сразу "нельзя"? Можно, просто к "твоему" коду поменьше доверия, что всё будет работать "искаропки" без особых сюрпризов, чем к продуктам Miscrosoft. Ну а что ты хотел?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Почему это сразу "нельзя"? Можно, просто к "твоему" коду поменьше доверия, что всё будет работать "искаропки" без особых сюрпризов, чем к продуктам Miscrosoft. Ну а что ты хотел?
Вот я и говорю двойные стандарты.
А самое противное, что на их основе делаются далеко идущие выводы.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
ГВ>>Почему это сразу "нельзя"? Можно, просто к "твоему" коду поменьше доверия, что всё будет работать "искаропки" без особых сюрпризов, чем к продуктам Miscrosoft. Ну а что ты хотел? WH>Вот я и говорю двойные стандарты. WH>А самое противное, что на их основе делаются далеко идущие выводы.
Посмотрим объективно. Что нам известно про Microsoft? Известно, что она делает удобные вещи и называет явления своими именами. Новых языков человеческого общения не создаёт, сиречь своих словарей не выпускает и по этому поводу пользователей идиотами не называет. Может быть она их таковыми где-то и считает (на что у меня есть свои соображения), но то, что она это не афиширует, говорит только в пользу MS — значит, она семь раз отмерит, один раз отрежет. Такой подход успокаивает.
Что нам известно про "WolfHound" (совпадение имён случайное)? Известно, что он называет синее — частично фиолетовым, фиолетовое — полукрасным, окружающих регулярно уличает в неправильном мышлении и грозится что-то общепринятое уничтожить как класс явлений. Такой подход настораживает сразу.
Ну и где здесь двойные стандарты? Система критериев одна и та же (как люди обращаются со словами и с аудиторией), только в случае MS она даёт один результат, а в твоём случае — прямо противоположный. Я тебя уверяю, ровно такое же отношение будет и к какой-нибудь малоизвестной фирме, которая выйдет на рынок с продуктом, скажем, класса Visual Studio, если она, паче чаяния, сопроводит это заявлениями на новоизобретённом языке. Заметь, я не говорю, что это невозможно, т.е. — что невозможно малоизвестной компании выпустить Visual Studio 2, я говорю только об отношении пользователей. Вполне возможно, что продукт будет на самом деле великих свойств и других достоинств, но тем не менее, доверять сходу ему будут только весьма отдельные товарищи.
Отсюда мораль: следи за языком.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
ГВ>Посмотрим объективно. Что нам известно про Microsoft? [...]
Известно также, что у неё есть огромная аудитория пользователей, которые, вроде бы, общаются.
ГВ>Что нам известно про "WolfHound"? [...]
Известно, что он представляет интересы очень узкой прослойки программистов-гиков, относительно которых известно, что на практике многие их творения "не стреляют", потому что "средние пользователи" — они, в общем, везде одинаковы, а гики — все очень сильно разные.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, AlexCab, Вы писали:
AC>Ну допусти вот пять из ООПаттернов(для краткости): Singleton, Factory, Adapter, Interface, Interpreter
Теперь давай подумает имеют ли эти понятия отношения к решаемой задаче или это все же попытки решить какие-то проблемы кодирования на конкретном языке.
На мой взгляд эти решают только одну проблему — проблему адаптации модели прикладной области к выбранному языку программирования.
Доказать это очень просто. Если взять другой язык, то некоторые (или даже все) из перечисленных паттернов станут бессмысленными. Например, первые два паттерна (Singleton, Factory) не имеют смысла в функциональном языке. А последний (Interpreter) бессмысленнен в любом динамическом языке обладающем функций eval.
Несколько интереснее паттерны вроде MCV. Но они скорее определяют архитектуру решения нежели используются при ее построении.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WolfHound, Вы писали:
VD>>Например, создав ДСЛ для описания ЯП, ты не освобождаешься от проектирования самого ЯП. WH>Ты взял язык для описания архитектуры и говоришь, вот видишь тут нужно архитектурить... очень смешно.
Если вывод не подтверждается хотя бы одним примером, то это ложный вывод.
WH>Ты мне лучше скажи, что ты собрался архитектурить в бухгалтерии?
Для этого тебя придется посвятить в ее нюансы. Поверь там есть чем заняться. В ней надо описывать взаимосвязь операций. Описывать правила формирования отчетов.
Если бухгалтерия является частью информационной системы предприятия, то все становится еще более кучеряво.
WH>Ведь после создания ДСЛ остается тупо открыть закон и переводить его в код.
Это примерно тоже самое, что сказать, что после прочтения Дракона нужно тупо взять любой ЯП и написать компилятор.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Шиворот навыворот.
Это потому что ты мыслишь понятиями ООП.
AVK>Это указатель на функцию это подходящая реализация для стратегии в том случае, когда стратегию можно описать одной функцией. Если нельзя — реализации будут либо объектами с несколькими методами, либо кортежом функций.
Все что можно посчитать, можно посчитать одной функцией. Но как ты верно заметил это уже детали реализации. Причем детали начинаются уже с того момента как ты приплел сюда какие-то стратегии. В исходной задачи их нет и быть не может. Ты ведь все так хорошо описывал, пока не переключился, внезапно, на паттерны, которые к задаче отношения не имеют.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>>Скажу больше. Твои слова "документ" и "ХО" уже говорят о том, что ты оперируешь не предметной областью, аз знакомым тебе алгоритмом (подходом).
AVK>Я описываю конкретный дизайн. Не задачу, а дизайн, понимаешь? Готовый.
О, как? А ты же говорил о проектировании. Не уж то можно вот так сразу готовый дизайн в один присест спроектировать?
VD>>В моем решении документ и ХО могут быть единым целым
AVK>И это другой дизайн.
Ага. Так какова связь паттернов и дизайна? Давай признаемся самим себе, что паттерны не более чем средство натягивания дизайна на выбранный язык.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>На мой взгляд эти решают только одну проблему — проблему адаптации модели прикладной области к выбранному языку программирования.
Думаю всё-таки ПП решают задачу дизайна/разработки(т.е. собственно проектирования) решения(некоторой проблемы в прикладно области), с тем чтобы оно удовлетворяло, и модели прикладной области, и модели ЯП(как ЯОН так и ПОЯ). VD>Доказать это очень просто. Если взять другой язык, то некоторые (или даже все) из перечисленных паттернов станут бессмысленными. Например, первые два паттерна (Singleton, Factory) не имеют смысла в функциональном языке.
Singleton — глобальная или размещённая в корне(в main'е) функция хранящая состояние.
Factory — функция-конструктор значений, инкапсулирует метод конструирования. VD>А последний (Interpreter) бессмысленнен в любом динамическом языке обладающем функций eval.
А сама функция eval(), является чем? (кроме того что является функцией) VD>Несколько интереснее паттерны вроде MCV. Но они скорее определяют архитектуру решения нежели используются при ее построении.
Какая по твоему разница между "определением" и "построением", в контексте проектирования ПО?
И пользуясь случаем хочу передать привет спросить: не потому ли WolfHound так люто-бешено разгоняет парсер, что нету компиляции кусочками, т.е. каждое изменение требует пересборки всей программы?
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали: AC>Например, у нас есть DSL для предметной области "Написание сообщения"(для форума), включающий возможности управления кареткой, вставки-удаления текста, и собственно отправки. Как его знание поможет мне понять смысл сообщения написанного при помощи этого DSL?
Никак. Это плохой язык. Он слишком общий — годится не только для "написания сообщения для форума", а вообще для любых текстов.
Для форума хорошим будет язык, который оперирует понятиями предметной области. Например "написать вброс", "перевести тему на личность собеседника", "процитировать классиков". С возможностью управлять стилем независимо от содержания и прочими плюшками.
А в каретки и вставки-удаления текста пускай компилятор переводит.
Вот такой язык поможет понять смысл сообщения, не вчитываясь в абзацы словесной шелухи, написанной единственно для переполнения входного буфера сознания читателя.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AlexCab, Вы писали:
AC>Не беспокоит, но в целом это плохо: AC>1)Толстый дистрибутив будет дольше скачиватся например. AC>2)Толстое приложение требует больше места на диске, и больше нагружает JIT(если для виртуалки). AC>3)Толстое приложение требует больше виртуальной памяти, оставляя меньше места для данных приложения. AC>Понятно что у нас толстые каналы, большие диски и x64, но считаю что всётаки стоит искать некую залотую середину между произволительность и размером кода.
Компактный читабельный код, написанный вручную, и длинный нечитаемый код, нагенеренный DSL-ем, могут создать примерно одинаковый по размеру байт-код.
Ну и плюс для .NET размер сборок обычно проблемы не составляет, а расход памяти и процесорного времени на JIT с лихвой может окупиться уменьшением расхода памяти и процессора на собственно обработку данных.
Здравствуйте, WolfHound, Вы писали:
I>>Конечно знаю, даже целых несколько. Можешь начать отсюда — http://kolesnik.ru/2006/pattern/ WH>И как это относится к тому, что микрософту можно заводить поля типов не явно, а мне нет? WH>Причинно-следственной связи не вижу. Совсем.
ГВ говорит про разницу в реализациях. В одной есть детали, в другой нет. А поля это только один из примеров.
"реализация "в лоб" попросту не вызывает никаких вопросов" и, я так понял, вопрос синхронизации тебе удобно игнорировать ? А как на счет перформанса ? Как быть с зависимыми пропертями, т.е. когда одно свойство изменяется при изменении нескольких других, что часто встречается.
Да и сам вопрос про поля нисколько не праздный. Например может оказаться, что нужно создавать наследников и переопределять некоторые свойства...
Ну и далее. Не совсем ясно, почему свой пример ты называешь борьбой с паттернами, если паттерн как был, так и остался, изменилось количество кода
Здравствуйте, Ikemefula, Вы писали:
I>ГВ говорит про разницу в реализациях. В одной есть детали, в другой нет. А поля это только один из примеров.
Он как обычно разводит демагогию.
I>"реализация "в лоб" попросту не вызывает никаких вопросов" и, я так понял, вопрос синхронизации тебе удобно игнорировать ? А как на счет перформанса ? Как быть с зависимыми пропертями, т.е. когда одно свойство изменяется при изменении нескольких других, что часто встречается.
И о чем это все? Если у меня в руках макросы я могу всё переделать как мне нужно.
I>Ну и далее. Не совсем ясно, почему свой пример ты называешь борьбой с паттернами, если паттерн как был, так и остался, изменилось количество кода
Ты, похоже, понятия предметной области называешь паттернами...
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexCab, Вы писали:
AC>И пользуясь случаем хочу передать привет спросить: не потому ли WolfHound так люто-бешено разгоняет парсер, что нету компиляции кусочками, т.е. каждое изменение требует пересборки всей программы?
Нет. Я его разгоняю, чтобы ты мог в реальном времени править мегабайтный файл и ИДЕ не тормозило.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
I>>ГВ говорит про разницу в реализациях. В одной есть детали, в другой нет. А поля это только один из примеров. WH>Он как обычно разводит демагогию.
Ты прочет так как тебе удобно и проигнорировал вопрос например про синхронизацию. В этом сообщении ты проигнорировал аналогичные вопросы от меня.
I>>"реализация "в лоб" попросту не вызывает никаких вопросов" и, я так понял, вопрос синхронизации тебе удобно игнорировать ? А как на счет перформанса ? Как быть с зависимыми пропертями, т.е. когда одно свойство изменяется при изменении нескольких других, что часто встречается. WH>И о чем это все? Если у меня в руках макросы я могу всё переделать как мне нужно.
1 И как глядя на декларацию класса узнать про эти детали ?
2 Каким дзеном нужно обладать, что бы догадаться какой атрибут использовать для конкретного решения ? С кодом как раз понятно, залез, посмотрел, глянул другие реализации и дело в шляпе. А как быть с макросами ? Наверное каждый программист должен написать свою реализацию
[ImpementsINotyfyPropertyChanged]
[ImpementsINotyfyPropertyChangedSynchronized]
[ImpementsINotyfyPropertyChangedNotSynchronizedButSupportSetterForOverload]
[ImpementsINotyfyPropertyChangedSynchronizedSupportDependentProperties]
[ImpementsINotyfyPropertyChangedSynchronizedSupportCtorInjection]
I>>Ну и далее. Не совсем ясно, почему свой пример ты называешь борьбой с паттернами, если паттерн как был, так и остался, изменилось количество кода WH>Ты, похоже, понятия предметной области называешь паттернами...
Покажи в своем примере "понятия предметной области", спасибо. Не облажайся только, потому как с моей стороны паттерн там есть в обоих реализациях понятия предметной области там нет вообще.
