Такое впечатление, что ты взял за основу своих рассуждений неверную посылку и теперь пытаешься всех вокруг воспитывать, подгоняя реальность под эту самую посылку. Паттерны — они прежде всего в голове, а потом уже в коде. Отсюда, кстати, прямой как рельса вывод: "библиотека" паттернов в принципе возможна только на бумаге. Библиотека программных реализаций будет всегда именно библиотекой программных реализаций. Самое важное отличие настоящей библиотеки описаний паттернов от библиотеки реализаций — это то, что в описаниях паттернов можно смело опустить тонкие детали реализации, а в реализациях — нет.
Хотя я не спорю, что в мире полно наивных программистов, которые так же наивно "пихают паттерны" куда угодно, а потом ищут глубокий смысл в постановке вещей с ног на голову. Но не надо делать далеко идущих выводов из чужих глупостей, ага?
WH>>>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть. ГВ>>Упрощенчество. Скажем, паттерн "фасад" можно выделить даже тут: WH>Как всегда. Написал, не поймешь что. И пытаешься строить далеко идущие выводы.
Это называется "иллюстрация". Иллюстрирует она то, что было кратко написано в комментариях: публичная компонента интерфейса объекта вполне может интерпретироваться как одна из реализаций паттерна "фасад".
WH>У тебя тут ни задачи. Без которой разговаривать не имеет смысла. Ни даже решения.
Прости, что использовал столь сложную технику, впредь постараюсь быть проще.
WH>>>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача. ГВ>>Или там, где нет необходимости вводить дополнительные конструкции в язык. WH>Она есть всегда, когда в языке нет возможности работать с терминами предметной области без костылей.
Правильно, только обрати внимание, ты сейчас соскальзываешь с паттернов на задачу реализации терминов предметной области. Я же тебе говорю, не уподобляйся идиотам — не смешивай разные по сути явления.
ГВ>>Скажу крамольную вещь: подчас проще оперировать "паттернами", чем конструкциями языками, их реализующими. WH>А ты пробовал оперировать языковыми конструкциями, когда ты можешь их в любой момент создать и переделать как угодно?
Пробовал, впечатления равноценны тем, что возникают, когда бесконечно совершенствуешь библиотеку. Шило на мыло. Заметь, я не говорю, что видоизменять язык — заведомо плохая практика, так же, как и совершенствовать библиотеку.
(Гы-гы, сейчас начнут говорить, что у меня дзен неправильный и дао не туда)
WH>Я пробовал. WH>Обратно на языки, которые это не могут, не хочу.
Вполне тебя понимаю, только что с того?
WH>Шаблоны С++ по сравнению с этим детский сад. Ясельная группа.
Ага, ну понятно, на сцене очередной "не-C++". Прикольно, C++ по-прежнему остаётся точкой отсчёта.
ГВ>>Связано это с тем, что "паттерн" является, в основном, мысленной конструкцией, и её можно легко адаптировать к реалиям того или иного языка. WH>Я предпочитаю языковые конструкции, которые могу легко адаптировать под себя.
Да на здоровье! Высказанного мной это никак не опровергает.
ГВ>>А вот языковая конструкция, реализующая паттерн — "чудище обло, огромно, стозевно и лаяй": по тем же причинам будет такой разнобой в реализациях, что мало не покажется. WH>Будет не больше чем разброд в библиотеках.
Угу, что и требовалось доказать.
WH>Ибо если язык позволяет вводить новые конструкции, то они автоматически становятся библиотеками.
Правильно. И так же автоматически перестают быть паттернами, становясь библиотеками. Забавная трансформация, правда?
WH>>>Ну, или разработчик не умеет пользоваться языком, на котором он пишет. Но этот случай не интересен. ГВ>>Как водится, лучший способ доказать неправильную посылку — свернуть на обсуждение личности. WH>А что у тебя есть другие варианты появления копипасты кроме слабости языка и некомпетентности? WH>Я других вариантов не знаю.
Во-первых, я знаю как минимум ещё один вариант появления копипасты — сознательное сохранение простоты кода.
Во-вторых, паттерны — это не всегда копипаста.
ГВ>>Лучший способ "бороться с паттернами" — употреблять их только в разговорной речи, а на языке программирования писать так, как он это позволяет. WH>Ага. WH>И получить кучу одинаковых визитеров, абстрактных фабрик итп.
Куча одинаковых визитеров, фабрик и т.п. — это нюансы реализаций. И что самое весёлое, что ровно та же куча одинаковых реализаций схожих, но уже языковых конструкций будет появляться в разных фирмах (или вообще — у разных программистов). И всё это будет происходить только из-за того, что источники изменений будут разрознены, т.е. ровно из-за того, из-за чего появляется разнобой в библиотеках.
WH>Ты пойми паттерны, они возникают в коде на языке недостаточно низкого уровня сами по себе. WH>Ни ты и ни кто другой не будет выдумать решение заново, если они уже решали практически такую же задачу. WH>И как только ты повторно используешь готовый подход к решению, ты получишь паттерн. WH>А я еще в первый раз расширю язык и во второй раз обойдусь без копипасты.
Скажи, будь добр, новая языковая конструкция будет ориентирована на конкретные типы данных и другие подобные конструкции, пусть даже описательного характера? Или она зависнет на воздусех и "сама" будет привязываться ко всему, чему угодно?
ГВ>>Ну, как всегда — будем лечить ангину простудой, обвиняя пациента в том, что он не умеет болеть. Знакомо, знакомо... WH>Как всегда ты не понял о чем разговор и ставишь диагнозы.
Среди нас двоих ровно один регулярно апеллирует к тому, что собеседник его "не понимает" и это точно не я. Извини, но может быть, тебе пора в зеркало посмотреть в поисках источника непонимания, а?
ГВ>>P.S.: Чую, пора уже заводить новый мем: "Количество языков в проекте растёт до тех пор, пока оно не превысит возможности программиста". WH>Ну, попробуй.
Уже.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, WolfHound, Вы писали:
I>>Например многие вещи сворачивать в функции категорически противопоказано, например если описывается какой то воркфлоу. Всем таким функциям нужно дать качественное имя а это далеко не всегда возможно, особенно если логика имеет эвристическое происхождение, а не математическое. WH>Зато можно сворачивать в язык.
Перечитай или попроси что бы тебе объяснили — в строчке повыше твоей речь не о "можно" а о "нужно". Нет хорошего имени — все твои абстракции окажутся мусором, даже если язык будет трижды простой.
I>>В сложных случаях лучше переходить на визуальные инструменты и в этом случае в принципе почти фиолетово, как будет выглядеть код. WH>Те графические ДСЛ для тебя приемлемы. WH>А текстовые, которые гораздо лучше нет. Интересная логика.
Передергиваешь в очередной раз. С чего ты взял что текстовые заведомо лучше графических ?
В некоторых областях текстовые будут лучше, до тех пор пока не появится качественная графическая информация.
Объяснение очень простое — текст для человека не является родным инструментом и никогда не будет. А во графика есть самый что ни есть родной.
Хочешь оспорить — предложи хороший текстовый язык взаимодействия пользоваетля с комьютером
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Хотя я не спорю, что в мире полно наивных программистов, которые так же наивно "пихают паттерны" куда угодно, а потом ищут глубокий смысл в постановке вещей с ног на голову. Но не надо делать далеко идущих выводов из чужих глупостей, ага?
Готов спорить, что в твоем коде полно паттернов.
Просто по тому, что ты пишешь на языке общего назначения.
А он про твою предметную область ничего не знает.
public class MyClass : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
private void OnPropertyChanged(string property)
{
if (PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs(property));
}
private int _MyProp;
public int MyProp
{
get { retunr _MyProp; }
set
{
if (value != _MyProp)
{
_MyProp = value;
OnPropertyChanged("MyProp");
}
}
}
}
И это будет в каждом классе реализующем INotifyPropertyChanged
И ты будешь это копипастить руками.
А в немерле я могу реализовать макроаттрибут ImplementINotifyPropertyChanged
И писать так:
[ImplementINotifyPropertyChanged]
public class MyClass
{
public MyProp : int { get; set; }
}
Вот это я называю паттернами и борьбой с ними.
ГВ>Правильно, только обрати внимание, ты сейчас соскальзываешь с паттернов на задачу реализации терминов предметной области. Я же тебе говорю, не уподобляйся идиотам — не смешивай разные по сути явления.
Паттерн возникает при реализации задачи предметной области на языке, который на эту предметную область не заточен.
См пример выше.
ГВ>Пробовал, впечатления равноценны тем, что возникают, когда бесконечно совершенствуешь библиотеку.
Извини, не поверю.
Просто все те, кто действительно этим занимался в реальных задачах, назад не хотят.
ГВ>(Гы-гы, сейчас начнут говорить, что у меня дзен неправильный и дао не туда)
Ну, так продемонстрируй свой дзен.
Только не говори что ты это на С++ных шаблонах делал.
Сразу засмею.
ГВ>Ага, ну понятно, на сцене очередной "не-C++". Прикольно, C++ по-прежнему остаётся точкой отсчёта.
Просто тут один орел заявляет что С++ это предел мечтаний.
WH>>Ибо если язык позволяет вводить новые конструкции, то они автоматически становятся библиотеками. ГВ>Правильно. И так же автоматически перестают быть паттернами, становясь библиотеками. Забавная трансформация, правда?
Так они именно за тем и вводятся, чтобы убить паттерны.
См пример выше.
Просто обычные библиотеки не могут убить паттерн. А языковые расширения могут.
Причем если при их использовании снова возникает паттерн мы можем повторить итерацию еще раз.
ГВ>Во-первых, я знаю как минимум ещё один вариант появления копипасты — сознательное сохранение простоты кода. ГВ>Во-вторых, паттерны — это не всегда копипаста.
Вот то, что выше это не копипаста да? И все паттерны они такие.
Паттерн он на то и паттерн что глядя на два куска кода видишь насколько они одинаковые.
Но сделать с этим ничего не можешь.
Ибо язык не позволяет.
ГВ>Куча одинаковых визитеров, фабрик и т.п. — это нюансы реализаций. И что самое весёлое, что ровно та же куча одинаковых реализаций схожих, но уже языковых конструкций будет появляться в разных фирмах (или вообще — у разных программистов). И всё это будет происходить только из-за того, что источники изменений будут разрознены, т.е. ровно из-за того, из-за чего появляется разнобой в библиотеках.
Разнобой вообще оффтопик.
Мы говорим про то, что паттерн это копипаста.
И про то, что с этим делать.
А то, что разные люди один и тот же паттерн убьют разными макрами к делу не относится.
Да и в любом случае особо распространённые паттерны будут убиваться стандартными макрами.
Так же как это сейчас происходит с библиотеками.
ГВ>Скажи, будь добр, новая языковая конструкция будет ориентирована на конкретные типы данных и другие подобные конструкции, пусть даже описательного характера? Или она зависнет на воздусех и "сама" будет привязываться ко всему, чему угодно?
А как реализуешь, так и будет. Отчет практика.
Здравствуйте, Ikemefula, Вы писали:
I>Эти сказки я уже слышу много лет. Еще в начале лета или весны ты рассказывал басни про увеличение продуктивности в 100-1000 раз, правда так и не рассказал, как же это ты вычислил и на чем это можно проверить.
Рассказал. Но ты демонстративно проигнорировал.
I>Вот посмотрим чего добьётся джетбрейнс с вашими мульками. Не дай бог продукты будут тормозить и глючить так же как и сейчас... Ну , ты понял Ожидаю, что джетбрейнс станет нумер1 в своей области. Если нет — немерле и дсл можно выкидывать в топку как академические бредни.
Он и так номер 1.
I>Покажи свои методы на примере сайта РСДН. А то крутых специалистов хоть лопатой греби, а сайт работает все хуже и хуже. Уже дерево топика нельзя толком раскрыть, а поиск не то что по сайту, уже по треду стал проблемой.
Я сайтом не занимаюсь.
I>Тебе показать, как вычищаются обращения к UI из кода где выкачиваются данные из БД ?
Или вот ещё ацкий трэш — у нас некоторые исключения имели помимо важности ещё свойство Color, которым (ааа111!!!) их надо было подсвечивать в GUI. Выставлялось это свойство автоматом, исходя из того в каком классе, в процессе работы над какой задачей, случился throw. Почему такое нарушение принципов вообще оказалось возможно — а потому что оно не выставлялось вручную вообще нигде. Т.е. GUI код просто использовал это свойство, и ему по-барабану как оно возникло, а программист который исключение кидал — даже не знал про какое-то там свойство, и его не выставлял. Соотвественно если бы мы решили эту хрень заменить, или вообще убрать — надо было бы менять только одно место, а значит принципы правильного разделения BL и GUI можно слать в конкретно этом случае лесом.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Перечитай или попроси что бы тебе объяснили — в строчке повыше твоей речь не о "можно" а о "нужно". Нет хорошего имени — все твои абстракции окажутся мусором, даже если язык будет трижды простой.
Понятно.
Показать задачу не можешь.
Ищешь отмазки.
I>Хочешь оспорить — предложи хороший текстовый язык взаимодействия пользоваетля с комьютером
Графика хорошо работает на мааааленьких объемах.
Но совершенно не масштабируется.
На досуге подумай, почему провалились все графические средства разработки.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ikemefula, Вы писали:
I>Снова враньё, я написал "Метод ForEach — итератор" а ты прочел это как "вызов метода". То ли ты врёшь, то ли читать не умеешь. Выбирай, мне всё равно.
Ты написал код, в котором вызвал метод.
Что ты там написал рядом текстом, не имеет значения.
WH>>Те паттерны, что в задаче не имею никакого отношения к паттернам в коде. I>Это не важно, природа у них одна и та же.
Абсолютно ничего общего.
Ты знаешь, есть такое слово "ключ"?
А ты знаешь, что оно означает?
WH>>Покажи мне задачу, в которой есть паттерн визитер или абстрактная фабрика или зиппер или scrap your boilerplate или любой другой. WH>>Именно задачу. А не решение. I>Цитирую себя: I>"паттерны возникают ... в решении задачи." Ты точно умеешь чиатть ?
Они в нем возникают, только если язык не адекватен задаче.
I>>>Упрощать нужно только и только в том случае, если код сложно и трудно майнтейнить. WH>>Любой код усложняет поддержку. I>Нет, не любой. Одна операция может запросто быть похожей на другую, но это вовсе не значит, что надо общую часть обязательно выделить в функцию или взять да обеспечить языковой поддержкой. Хорошего имени может просто и не быть, что обычное дело если логика суть эвристики.
Код в студию.
Без кода это все пустой треп.
I>Функционалисты вроде тебя заменяют такое на закорючки и прочую ересь которую мало кто станет изучать.
Я не функционалист.
I>Это слишком категорично и безосновательно. Хорошо бы увидеть некоторые замеры, скажем "после тотального устранения лишнего кода производительность программистов увеличиалсть на А%, где А рассчитано по методика Б, проверено по методике В на программистах N проектов, увеличение производительности позволило увеличить продажина K%"
Когда код сокращается раз в 10 это все исследования теряют смысл. Re[4]: Паттерны проектирования — копипаста!
Здравствуйте, WolfHound, Вы писали:
I>>Снова враньё, я написал "Метод ForEach — итератор" а ты прочел это как "вызов метода". То ли ты врёшь, то ли читать не умеешь. Выбирай, мне всё равно. WH>Ты написал код, в котором вызвал метод. WH>Что ты там написал рядом текстом, не имеет значения.
Имеет. Если нет, то я твой текст так же буду считать не имеющим значения. Идёт ?
WH>>>Те паттерны, что в задаче не имею никакого отношения к паттернам в коде. I>>Это не важно, природа у них одна и та же. WH>Абсолютно ничего общего.
Это и есть заблуждение. Паттерны есть следствие особенностей человеческого мышления. Неважно, какие ты задачи решаешь, после решения N схожих задач обязательно появляется паттерн. Какие именно задачи, бледжек или перевод в код модели игры в блекджек — абсолютно не важно.
WH>>>Покажи мне задачу, в которой есть паттерн визитер или абстрактная фабрика или зиппер или scrap your boilerplate или любой другой. WH>>>Именно задачу. А не решение. I>>Цитирую себя: I>>"паттерны возникают ... в решении задачи." Ты точно умеешь чиатть ? WH>Они в нем возникают, только если язык не адекватен задаче.
Возвращаемся к примеру про блекджек. Вообще бери любое сеймейство задач — там гарантировано появятся паттерны в процессе решения.
I>>Нет, не любой. Одна операция может запросто быть похожей на другую, но это вовсе не значит, что надо общую часть обязательно выделить в функцию или взять да обеспечить языковой поддержкой. Хорошего имени может просто и не быть, что обычное дело если логика суть эвристики. WH>Код в студию. WH>Без кода это все пустой треп.
Я уже знаю, что ты хочешь сказать про эвристики: "мне так хочется" -> "в лес". Ты забыл, что это уже было и даже несколько раз ?
I>>Функционалисты вроде тебя заменяют такое на закорючки и прочую ересь которую мало кто станет изучать. WH>Я не функционалист.
Он самый
I>>Это слишком категорично и безосновательно. Хорошо бы увидеть некоторые замеры, скажем "после тотального устранения лишнего кода производительность программистов увеличиалсть на А%, где А рассчитано по методика Б, проверено по методике В на программистах N проектов, увеличение производительности позволило увеличить продажина K%" WH>Когда код сокращается раз в 10 это все исследования теряют смысл. WH>Re[4]: Паттерны проектирования — копипаста!
Очевидно, заблуждение. Нужно показать как это влияет на профит конторы. Например увеличение продаж, вытеснение конкурентов — то это круто. Если нет — ну и хрен с ним, с твоим коротким кодом.
Здравствуйте, WolfHound, Вы писали: WH>Ибо что такое паттерн? Паттерн это повторяющийся код. Копипаста как она есть.
Думаю ты перепутал паттерны проектирования(вроде ООП паттернов(фабрики, визиторы etc.)) применяемые на этапе проектирования(разработки архитектуры), с паттернами кодирования(вроде алгоритмов)применяемыми при кодировании(а точнее при разработке кода по архитектуре). Например на этапе проектирования решается будет ли в приложении фабрика объектов в принципе, а на этапе кодирования решается реализовать ли её например в виде класса, шаблона, встроена в транслятор предметного ЯП etc.
Паттерны кодирования как раз и приводят к дублированию кода(эта проблема традиционно решается вынесением дулирующегося кода например в функцию/макрос, разработкой DSL'а("вынесением в транслятор") etc.). WH>Паттерны возникают там, где не достаточно выразительности языка программирования, на котором решается задача.
Не, паттерны это решения типичных проблем, соответственно возникают они там где есть такие проблемы. WH>Соответственно если у нас первый случай то единственный способ бороться с паттернами это взять язык, который поддерживает сущности предметной области. К сожалению, для чуть менее чем всех предметных областей таких языков нет.
Разве программы на DSL не нужно проектировать? WH>Вот и приходится людям жрать кактус. Ибо далеко не всем хватает смелости сделать свой язык для того чтобы решить задачу.
Не, это потому что, на сегодня:
1)Решить задачу(даже небольшой класс задач) в лоб сильно проще чем разработать ЯП для её решения.
2)Из первого следует, что для решения задачи в лоб можно нанять одного посредственного программиста, и сэкономить деньгу.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Думаю ты перепутал паттерны проектирования(вроде ООП паттернов(фабрики, визиторы etc.)) применяемые на этапе проектирования(разработки архитектуры), с паттернами кодирования(вроде алгоритмов)применяемыми при кодировании(а точнее при разработке кода по архитектуре). Например на этапе проектирования решается будет ли в приложении фабрика объектов в принципе, а на этапе кодирования решается реализовать ли её например в виде класса, шаблона, встроена в транслятор предметного ЯП etc.
Я ничего не перепутал.
Это одно и то же.
Ибо я не знаю ни одной модели предметной области, в которой была бы фабрика объектов. Или визитёр. Или зиппер.
Они всегда появляются на этапе превращения модели предметной области в код.
Причем в коде на яве ты не увидишь зиппер, а в коде на хаскеле абстрактную фабрику.
Ибо свойства языков очень разные и паттерны при реализации даже одной и той же задачи на разных языках получатся разными.
AC>Не, паттерны это решения типичных проблем, соответственно возникают они там где есть такие проблемы.
Ну да. Типичные проблемы при реализации кода на конкретном языке.
AC>Разве программы на DSL не нужно проектировать?
Проектирование == создание ДСЛ.
А дальше уже остается чистая бизнес логика.
Там нечего проектировать.
И нет никаких паттернов.
AC>1)Решить задачу(даже небольшой класс задач) в лоб сильно проще чем разработать ЯП для её решения.
Не правда.
Особенно если это не разработка, а расширение уже существующего.
AC>2)Из первого следует, что для решения задачи в лоб можно нанять одного посредственного программиста, и сэкономить деньгу.
И потом когда станет ясно, что это всё не работает нанять еще одного, но дорогого. Который сделает все в 10 раз быстрее и в 2 раза дешевле даже не смотря на то, что ему приходится платить в 5 раз больше. Ибо в 10 раз быстрее.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
WH>>Проектирование == создание ДСЛ. WH>>А дальше уже остается чистая бизнес логика. WH>>Там нечего проектировать. AVK>Сильное заявление.
И что же нужно проектировать кода у тебя остается только код бизнес логики без намеков на детали реализации?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
WH>Я ничего не перепутал. WH>Это одно и то же.
Нет, паттерны проектирования не могут приводить к дублированию кода, потому что на этом этапе нет кода, есть модули, процессы, объекты, этапы etc.
А уже на этапе разработки(когда архитектура уже готова и её можно воплотить в коде) появляются функции, потоки, классы etc. И тут как раз паттерны помогают избежать копипасты и избыточной сложности, так как позволяют использовать готовые решения(а не изобретать собственные велосипеды), в том числе и из готовых библиотек(а не переписывать всё заново). WH>Ибо я не знаю ни одной модели предметной области, в которой была бы фабрика объектов. Или визитёр. Или зиппер.
ООП?
Паттрены проектирования есть везде где есть собственно проектирование(в любой п.области).
Но я думаю ты всё-таки имел ввиду предметно-прикладные области. Так вот там тоже есть паттерны. Откуда по твоему взялись ООП паттерны? Это типичные и удачные ПОО решение типичных проблем встречающихся в _разных_ предметных областях.
Я уверен, подобные паттерны существуют (будут) для тех-же типичных проблем, решаемых с помощью ИП, ФП, DSL etc. WH>Они всегда появляются на этапе превращения модели предметной области в код.
Не согласен, паттерны проектирования(такие как например ООП паттерны) появляются на этапе проектирования модели предметной области, пригодной для превращения в код. WH>Причем в коде на яве ты не увидишь зиппер, а в коде на хаскеле абстрактную фабрику.
Там вероятно есть свои паттерны, являющиеся решением те же проблемы. WH>Ну да. Типичные проблемы при реализации кода на конкретном языке.
Есть среди них и такие. AC>>Разве программы на DSL не нужно проектировать? WH>Проектирование == создание ДСЛ.
При создании DSL не будут использоваться паттерны? WH>А дальше уже остается чистая бизнес логика. WH>Там нечего проектировать.
Подозреваю что ты представляеш себе разработку ПО как-то так: сделаем один DSL, поверх него ещё один, поверх второго третий,... последний DSL будет содержать единственный оператор "работай"? WH>Особенно если это не разработка, а расширение уже существующего.
Возможно, но люди всегда ищут наиболее выгодный/короткий путь, потому если-бы разработка ЯП была выгодней думаю, всё бы так и делали. WH>И потом когда станет ясно, что это всё не работает нанять еще одного, но дорогого. Который сделает все в 10 раз быстрее и в 2 раза дешевле даже не смотря на то, что ему приходится платить в 5 раз больше. Ибо в 10 раз быстрее.
Такое тоже бывает, но думаю не часто, иначе-бы некто не нанимал посредственных программистов, и они бы извелись как класс.
Между тем,что я думаю,тем,что я хочу сказать,тем,что я,как мне кажется,говорю,и тем,что вы хотите услышать,тем,что как вам кажется,вы слышите,тем,что вы понимаете,стоит десять вариантов возникновения непонимания.Но всё-таки давайте попробуем...(Э.Уэллс)
Здравствуйте, AlexCab, Вы писали:
AC>Нет, паттерны проектирования не могут приводить к дублированию кода, потому что на этом этапе нет кода, есть модули, процессы, объекты, этапы etc.
Они по тому и паттерны что их очень легко узнать.
А раз легко узнать значит, есть дублирование кода.
Просто по определению.
AC>А уже на этапе разработки(когда архитектура уже готова и её можно воплотить в коде) появляются функции, потоки, классы etc.
Архитекру делают под язык программирования, на котором будут писать код.
Ибо если ты попытаешься реализовать архитектуру, сделанную для явы на хаскеле или наоборот то у тебя получится такой кошмар что аж жуть.
Таким образом классы итп появляются еще до того как начинают писать код.
AC>И тут как раз паттерны помогают избежать копипасты и избыточной сложности,
Так они и есть копипаста и избыточный код.
AC> так как позволяют использовать готовые решения(а не изобретать собственные велосипеды), в том числе и из готовых библиотек(а не переписывать всё заново).
Вызов метода не паттерн.
Ибо иначе у нас вообще все становится паттерном. И весь разговор теряет смысл.
AC>ООП?
ООП не предметная область.
AC>Паттрены проектирования есть везде где есть собственно проектирование(в любой п.области).
Они есть только там, где язык заставляет писать похожий код.
Само название паттерн указывает на то что-то повторяется много раз.
AC>Но я думаю ты всё-таки имел ввиду предметно-прикладные области. Так вот там тоже есть паттерны. Откуда по твоему взялись ООП паттерны? Это типичные и удачные ПОО решение типичных проблем встречающихся в _разных_ предметных областях.
Вот именно. ООП решение
А если делать язык, который работает в терминах предметной области, то паттерны исчезают.
AC>Я уверен, подобные паттерны существуют (будут) для тех-же типичных проблем, решаемых с помощью ИП, ФП, DSL etc.
Для ИП и ФП будут. А для DSL не будут.
Просто по тому, что ДСЛ работает в терминах предметной области.
WH>>Они всегда появляются на этапе превращения модели предметной области в код. AC>Не согласен, паттерны проектирования(такие как например ООП паттерны) появляются на этапе проектирования модели предметной области, пригодной для превращения в код.
Ох. Проектирование всегда ведется под конкретный язык.
И в проект сразу закладываются ограничения языка.
И из-за ограничений языка появляются паттерны.
Если же у языка в рамках данной задачи нет ограничений, то паттерны не появляются.
WH>>Причем в коде на яве ты не увидишь зиппер, а в коде на хаскеле абстрактную фабрику. AC>Там вероятно есть свои паттерны, являющиеся решением те же проблемы.
Так, а я про что говорю?
Я и говорю, что паттерны типичны для конкретного языка. Ну, или группы очень похожих языков.
А если брать не похожий язык, то там и паттерны получаются совершенно другими.
А если язык заточен под конкретную задачу, то там паттерны не появляются вообще.
Ибо источник паттернов это несоответствие языка задаче.
WH>>Ну да. Типичные проблемы при реализации кода на конкретном языке. AC>Есть среди них и такие.
Они все такие. 100%.
AC>>>Разве программы на DSL не нужно проектировать? WH>>Проектирование == создание ДСЛ. AC>При создании DSL не будут использоваться паттерны?
Зачем?
Когда ты генерируешь код из ДСЛ можно генерировать что угодно.
Главное чтобы работало. И работало быстро.
Вот, например я сейчас занимаюсь оптимизацией одного ДСЛ.
Генерирую такой говнокод что за ручное написание такого оторвал бы руки.
Но так как код генерируется то всем пофиг на, то, что его ни написать, ни прочитать.
За то все летать будет.
AC>Подозреваю что ты представляеш себе разработку ПО как-то так: сделаем один DSL, поверх него ещё один, поверх второго третий,... последний DSL будет содержать единственный оператор "работай"?
Сарказм не получился.
Ибо я так не только думаю. Но и делаю.
AC>Возможно, но люди всегда ищут наиболее выгодный/короткий путь, потому если-бы разработка ЯП была выгодней думаю, всё бы так и делали. Так те кто не боится делает.
Но большенство людей настолько боятся перемен что не хотят даже взглянуть.
AC>Такое тоже бывает, но думаю не часто, иначе-бы некто не нанимал посредственных программистов, и они бы извелись как класс.
Людская жадность крайне иррациональна.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>И что же нужно проектировать кода у тебя остается только код бизнес логики без намеков на детали реализации?
Бизнес-логику, разумеется. Ты же не думаешь что реальная бизнес логика это как в игрушечных примерах, простенький алгоритм с минимумом входных и выходных параметров?
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Здравствуйте, WolfHound, Вы писали:
WH>Они по тому и паттерны что их очень легко узнать. WH>А раз легко узнать значит, есть дублирование кода. WH>Просто по определению.
Давай рассмотрим реальный, хоть и упрощенный, пример, ОК? Предметная область — бухгалтерия. В ней есть некие документы разных типов. И у каждого документа есть специальный алгоритм, или даже более обще — специальная функция, преобразующая данные документа в набор специальных сущностей — хозопераций (ХО это атомарное перемещение денег со счета на счет, но не суть). Наконец, есть универсальная рукоятка, позволяющая по набору разнотипных документов вычислить для них хозоперации.
На этапе проектирования бизнес-логики мы оформляем собтвенно функцию перехода от документа конкретного типа к набору ХО как специальную сущность, видимую пользователю (потому что у него должна быть возможность самостоятельно выбирать такую функцию для конкретного типа документов).
Обрати внимание, я ни слова не сказал про языки программирования и какой либо код.
Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией. Т.е. мы использовали паттерн. Или, если не синтетически, а аналитически, мы можем назвать использованное решение паттерном.
Теперь вопрос — как в описанной цепочке DSL помогут куда то там деть паттерн? До DSL еще даже не дошло, пока только очень крупноблочный дизайн описан, а паттерны уже есть. И да, паттерны это не только совсем примитивные вещи типа фабрики или стратегии (эти паттерны ценны скорее как словарь для описания софтварных проектов), есть и более сложные вещи, типа MVC/MVVM, message bus и даже целые книжки навроде ITIL.
WH>Само название паттерн указывает на то что-то повторяется много раз.
Не что то, а дизайн. Не код, дизайн, понимаешь?
... << RSDN@Home 1.2.0 alpha 5 rev. 65 on Windows 7 6.1.7601.65536>>
Это не паттерн, а его реализация. Скажу больше, это одна из возможных реализаций Наблюдателя.
WH>И это будет в каждом классе реализующем INotifyPropertyChanged WH>И ты будешь это копипастить руками. WH>А в немерле я могу реализовать макроаттрибут ImplementINotifyPropertyChanged WH>И писать так: WH>
WH>[ImplementINotifyPropertyChanged]
WH>public class MyClass
WH>{
WH> public MyProp : int { get; set; }
WH>}
WH>
А это реализация того же самого паттерна, но на другом языке.
WH>Вот это я называю паттернами и борьбой с ними.
Где борьба то? Паттерн как был, так и остался. Чем характеризуется паттерн? Задачей и ее решением. Причем, решение — это не конкретная реализация, а обобщенное описание решения. И что же поменялось? Да ничего, ты просто спрятал под капот небольшую часть ручной работы, даже интерфейс остался без изменений.
Здравствуйте, Игoрь, Вы писали:
И>Это не паттерн, а его реализация. Скажу больше, это одна из возможных реализаций Наблюдателя.
Ох. Что такое паттерн.
Паттерн это нечто повторяющееся.
Например, посмотри в гугле картинки по слову pattern.
Увидишь много картинок, на которых повторяется что-то.
И>А это реализация того же самого паттерна, но на другом языке.
Тут нет паттерна.
Вот эта хрень не повторяется.
private int _MyProp;
public int MyProp
{
get { retunr _MyProp; }
set
{
if (value != _MyProp)
{
_MyProp = value;
OnPropertyChanged("MyProp");
}
}
}
И>Где борьба то? Паттерн как был, так и остался.
Как это остался?
Где повторение вон той хрени чуть выше по тексту?
И>Чем характеризуется паттерн? Задачей и ее решением.
Нет. Он характеризуется повторяющимся кодом.
Ты извращаешь понятие паттерн.
Паттерн это не решение. Это распознаватель решения.
И>Причем, решение — это не конкретная реализация, а обобщенное описание решения. И что же поменялось? Да ничего, ты просто спрятал под капот небольшую часть ручной работы, даже интерфейс остался без изменений.
Скукорживание кода на порядок это конечно да... часть не большая.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Бизнес-логику, разумеется. Ты же не думаешь что реальная бизнес логика это как в игрушечных примерах, простенький алгоритм с минимумом входных и выходных параметров?
И что же там проектировать то?
Ты надеюсь, сбор требований с проектированием не путаешь?
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Так вот — вот эта специальная сущность-функция на языке паттернов называется стратегией. Т.е. мы использовали паттерн. Или, если не синтетически, а аналитически, мы можем назвать использованное решение паттерном.
Еще один. Народ вам не надоело вызов одной функции назвать паттерном?
Такими темпами в паттерны можно записать буквально всё.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Ожидаю, что джетбрейнс станет нумер1 в своей области. Если нет — немерле и дсл можно выкидывать в топку как академические бредни.
