Re: Суть паттернов и других подходов в программировании
От: Ops Россия  
Дата: 06.08.14 08:10
Оценка: +4 -3
Здравствуйте, Alllie, Вы писали:

Паттерны — это договор программистов о терминологии. Все.
Сами подходы, описываемые паттернами, довольно очевидны даже при небольшом опыте. И единственное применение им — правильно (и коротко) назвать свое решение, чтобы другие поняли.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[7]: Суть паттернов и других подходов в программировании
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.08.14 15:57
Оценка: 10 (2) +3
Здравствуйте, Alllie, Вы писали:

A>Мы все же про разные паттерны.

Это одни и те же паттерны. Просто к одним вы настолько привыкли, что они уже не кажутся вам паттернами. А другие пока что не вошли в тот язык программирования, на котором вы думаете, поэтому вам кажется, что они какие-то "особенные".

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

Пример с вызовом процедуры очень показателен. Если вы отвлечётесь от привычных вам процедурных языков программирования, то окажется, что есть частая проблема "вызвать процедуру с параметрами, с поддержкой реентерабельности". Если бы нам не нужна была реентерабельность, то мы могли бы передавать параметры через, скажем, глобальные переменные. То есть процедура знает, что по адресу 0x12310004 лежит параметр А, а по адресу 0x12310008 — параметр Б. Именно так устроены типичные программы для Машины Тьюринга.
А вот реентерабельность требует, чтобы у каждого "экземпляра вызова" процедуры был свой набор параметров и локальных переменных. И вот внезапно нас озаряет: давайте придумаем паттерн "передача параметров через Стек". Его нетрудно соорудить из подручных материалов — даже если бы в нашем ассемблере не было бы удобных стековых команд, это бы никак нам не помешало:
add esi, 4
mov [esi], 0x00000001 // параметр 1
add esi, 4
mov [esi], 0x00000010 // параметр 2
add esi, 4
mov [esi], eip // сохранили адрес возврата
jmp 0x124463463463 // адрес пролога процедуры

в эпилоге процедура извлечёт адрес возврата из стека и сделает на него jmp.
Вот мы собрали из камней и палок мощную концепцию.
Понятно, что все процедуры — разные. Количество и типы аргументов отличаются; поэтому конкретные блоки кода по вызову процедуры отличаются. Тем не менее, во всех них есть что-то общее.
и вот мы начинаем выделять "паттерны" и делать их частью языка. сначала мы заменяем пару add esi, 4 / mov [esi] XXX на push XXX. Затем — push/jmp мы заменяем на call, а pop/jmp на ret.
В итоге наш код становится одновременно понятнее и короче.

Затем мы переходим на уровень выше, и вводим понятие "сигнатура процедуры", которое позволяет нам отделить задачу "вызов с параметрами" от её решения.
Заодно это позволяет нам легким движением руки вносить модификации в реализацию этого паттерна — например, мы можем оптимизировать вызовы при помощи передачи части аргументов в регистрах. Мощь паттерна, реализованного в языке — в том, что детали реализации отделены от деталей задачи.

Всё то же самое применимо и к другим паттернам. Паттерн "фабрика" приходится вводить в тех языках, где нет понятия фабрика.

В дельфи фабрики не нужны от слова "совсем". В C# не нужнен паттерн "Publisher/Subscriber", потому что есть языковые понятия event и delegate.

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

То есть мы как бы знаем понятия "подпрограмма", "сигнатура", "вызов подпрограммы", "возврат", но вынуждены по-прежнему писать в терминах add, mov, и jmp.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Суть паттернов и других подходов в программировании
От: Vaako Украина  
Дата: 06.08.14 12:09
Оценка: +2 :)))
Здравствуйте, Sinix, Вы писали:

Зато усилия по натягиванию паттернов на код и последствия я сам наблюдал и чинил неоднократно


не натягиваются — все время либо узкие либо телепаются лишними ошметками.
Re[4]: Суть паттернов и других подходов в программировании
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.08.14 10:07
Оценка: 26 (3) :)
Здравствуйте, Alllie, Вы писали:

A>Здравствуйте, Baudolino, Вы писали:


B>>Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату.


A>Вот это уже интереснее, что за подход такой "системный и объектно-ориентированный анализ"?

Это разные походы. Системный анализ — это рекурсиваня декомпозиция. В начале мы имеем одну большую систему, потом начинаем из нее выделать подсистемы, из них потом тоже подсистемы и так далее.
ОО-анализ это "давайте все опишем с помощью системы взаимодействующих объектов с состянием и поведением".
Буч и Мейер пытались смешать эти два подхода, не получилось, слишком мало общего между ними. Буча вообще смешно читать, он при описаниях использует системный подход, а пишет чисто ООПшный код для примеров, где границы описанных систем не видны.

A>Реально помогает принимать правильные решения?

Системный — да. ОО-анализ — нет.

A>И какие приемы, методики в рамках данного анализа существуют?

A>Применяли ли вы эти методы в практике?

В системном анализе мало конкретных приемов, это слишком общая методика.

Вообще тебе стоит прочитать "Design of Design" Брукса (того самого, который написал Мифический человеко-месяц)
Re: Суть паттернов и других подходов в программировании
От: Baudolino  
Дата: 06.08.14 08:42
Оценка: 14 (2) +2
A>То есть, что бы правильно применять паттерн, нужно понимать его суть, его плюсы и минусы, а так же необходимо четко определить, что у нас есть иммено тот тип проблемы, который эффективно решается этим паттерном.
A>Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)?
Трехзвенная архитектура — тоже паттерн.

A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?

Да. Архитектура должна всегда однозначно вытекать из требований. Предположим, у вас на каком-то этапе проектирования появилось несколько вариантов решения, имеющих свои преимущества и недостатки (производительность, юзабилити, сроки, стоимость и т.п.), и требования ничего не говорят о том, какое решение выбрать. Тогда вы берете за шкирку заказчика (business owner), сажаете его за стол и совместно доопределяете требования таким образом, чтобы выбор был однозначен. Основное достоинство архитектурных паттернов в этой ситуации заключается в том, что большую часть анализа за вас уже проделали, плюсы и минусы выявлены, осталось только сопоставить их с требованиями и закрыть пробелы обосновании решений.

Коллега Ops, который тут высказался в духе, что паттерны — это только терминология, не совсем прав. Основная их ценность не в том, что какой-то дизайн назван удобным словом (иначе можно было бы придумывать слова и для абсолютно никчемных архитектур и называть это паттернами), а в том, что кто-то уже проделал аналитическую работу, выявил полезные типовые решения и описал область их применения.

Здесь часто появляются комментарии в стиле, что паттерны — это никому не нужная ерунда, они только мешают, и позволяют писать слишком запутанный и переусложненный код. В действительности, это перекладывание проблемы с больной головы на здоровую: человек, который написал плохой код, не понимал, что он пишет (не сопоставил область применения паттерна с требованиями, не нарисовал эти столбики плюсов и минусов хотя бы у себя в голове), а виноватым оказывается инструмент. Это говорит лишь о том, что авторы подобных комментариев и сами плохо понимают предмет.
Re[9]: Суть паттернов и других подходов в программировании
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.08.14 07:55
Оценка: 6 (2) +2
Здравствуйте, dimgel, Вы писали:
D>Всё-таки мне думается, ты смешиваешь понятие "паттерн" (который суть чистая идея, абстракция) и "реализация паттерна". В твоём примере event/delegate — реализация паттерна publisher/subscriber на конкретном языке. Принципиально нет никакой разницы, реализован паттерн средствами языка, DSL или библиотеки; разница только в удобстве использования.

Конечно же ты прав. Но в самой чистой идее есть какие-то конкретные черты, благодаря которым мы можем понять, что вот этот код — это фабрика, а тот код — не фабрика.
Если таки открыть любой источник, рассуждающий в терминах паттернов, то окажется, что там приведено вполне конкретное решение.
Вот, например, http://citforum.ru/SE/project/pattern/p_2.shtml#3.3.1:

Решение: Создать абстрактный класс, в котором объявлен интерфейс для создания конкретных классов.

То есть — сразу имеем
public abstract class ControlFactory
{
  public abstract Control CreateControl(Control parent);
}

Конечно, в уме мы понимаем, что вот это решение, несмотря на свою претензию на всеобщность, рассчитано на совершенно конкретный язык программирования. В том же C# вполне идиоматичным будет и
public interface IControlFactory
{
  Control CreateControl(Conrol parent);
}

и
public delegate Control ControlFactory(Control parent);

и даже
using ControlFactory = Action<Сontrol, Control>;

Использование терминов типа "абстрактный класс" сразу же выдаёт родной язык авторов паттерна.

Конечно же, когда мы говорим о языковом понятии, мы фиксируем какую-то более-менее конкретную реализацию абстрактного понятия.
В зависимости от предпочтений авторов языка, можно либо вообще зафиксировать ровно одну реализацию (например, параллельная иерархия метаклассов в Delphi, которые, в сочетании с виртуальными конструкторами могут выступать в качестве абстрактных фабрик), либо дать на выбор несколько реализаций (например, virtual и dynamic methods в том же Delphi используют разную структуру VMT), либо вообще отделить реализацию от декларации (например, query expressions в Linq).

Тем не менее, нужно понимать, что при грамотной реализации, языковое понятие на 99.99% устраняет нужду в самом понятии "паттерна".
Типичным примером является паттерн "procedure call". Несмотря на то, что это — всего лишь "чистая идея", "абстракция", подавляющее большинство программистов не только не отдают себе отчёт в существовании такого паттерна, но зачастую не верят в него даже после наглядной демонстрации.

За десятилетия существования "встроенных реализаций" этого паттерна даже различия в его реализации выкристаллизовались в отдельное понятие "calling convention".

Поэтому в современном мире можно спокойно игнорировать наличие абстрактных идей в практически любой коммуникации между разработчиками, и уж тем более — в рамках одного проекта.
Никто не говорит "используй паттерн Реентерабельный Вызов Процедуры в сочетании с паттерном Таблица Виртуализуемых Методов". Говорят "вызови метод IHttpHandler.ProcessRequest()".

Точно так же в Delphi проектах никто не говорит "используй паттерн Абстрактная Фабрика для того, чтобы позволить прикладному программисту заменять тип создаваемых объектов". Говорят "добавь свойство ChildItemType классового типа, и вызывай виртуальный конструктор на нём".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re: Суть паттернов и других подходов в программировании
От: 0x7be СССР  
Дата: 06.08.14 08:28
Оценка: 24 (2) +1
Здравствуйте, Alllie, Вы писали:

A>Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)?

A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?
Microsoft Application Architecture Guide, 2nd Edition

Если в двух словах, то выбор правильной архитектуры диктуется двумя вещами:
1. Четким пониманием цели и назначения системы, предъявляемых к ней функциональных и нефункциональных требований.
2. Знанием и пониманием свойств тех или иных архитектурных паттернов и решений, доступных платформ, технологий и т.п.

Ну а дальше итеративный процесс:
1. Набросал ахритектуру.
2. Промоделировал её свойства, насколько вписываются в неё сценарии работы системы, оценил соответствие NFR`ам.
3. Оценил результат, если недостаточно хорошо, вернулся к п.1
Re[7]: Суть паттернов и других подходов в программировании
От: Ops Россия  
Дата: 08.08.14 19:36
Оценка: +2 :)
Здравствуйте, ononim, Вы писали:

O>Профессионалы пользуюся рулетками.

КМК, лазерный дальномер удобнее.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[2]: Суть паттернов и других подходов в программировании
От: dimgel Россия https://github.com/dimgel
Дата: 13.08.14 20:50
Оценка: 20 (1) +1
Здравствуйте, Sinix, Вы писали:

S>А вот тут, на мой взгляд, лучше вообще не пытаться использовать паттерны как аргумент для выбора. Для отдельных решений ошибочно выбранный паттерн ещё можно исправить, а вот основу архитектуры лучше закладывать исходя из практических соображений. Смотреть на характер нагрузки, уровень команды, опыт похожих решений, используемый язык/фреймворк и т.д. и т.п. Абстрактных универсальных ответов тут нет и не может быть


Очень похожие соображения совсем недавно Тёма добавил в Ководство: Правило по составлению правил — у него про дизайн, но фактически это универсальное правило. Ну ещё вспоминается из Фаулера
Автор: Дм.Григорьев
Дата: 02.07.07
.
Re[2]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.08.14 08:58
Оценка: 4 (1) +1
Здравствуйте, WolfHound, Вы писали:

A>>Первый вопрос: как находить суть паттернов?

WH>Паттерн это копипаста неустранимая средствами выбранного языка.
WH>В похожих языках (C# и Java) паттерны похожи. В сильно разных (C# и haskell) сильно разные.
WH>В языках с качественным метапрограммированием найти паттерны не просто. Ибо трудно придумать копипасту которую не устранить метапрограммированием.

Паттерн это не копипаста. Вопрос не в том, можно ли устранить паттерн, вопрос в том, можно ли устряняя паттерн сделать код более понятным тем, кто с ним работает.
Если просто так устранять паттерны на том основании, что это копипаста(непонятный термин), то окажется так, что программу сможет прочесть только компилятор.

Если внимательно посмотреть, откуда берутся паттерны, то увидим, что там, где есть цыклы, есть и соответсвующие паттерны. Есть всевозможные запросы — будут и паттерны. То есть, любая языковая фича даёт паттерны. Вопрос тольк в количестве кода.

Отсюда ясно, что единсвенный код, где нет паттернов это "DoAll"

Вот так, что бы кода было много и весь на метапрограммировании, и не было паттернов — это в принципе невозможно. Любая более менее устойчивая структура будет паттерном. Например в языках с метапрограммированием паттерны нужно искать в библиотеках макросов. Понятно, что метапрограммирование не устраняет паттерны. Эти самые паттерны просто кочуют в библиотеки макросов и компилятор.

Вообще паттерны это естественный этап накопления опыта. Во всех без исключения областях деятельности человека есть эти самые паттерны. Скажем "сицилианская защита" в шахматах это обычный паттерн. Или например "королевский гамбит" это целое семейство паттернов.

Правильные вопросы про паттерны — как ими пользоваться и почему они собственно вознимают.
Re: Суть паттернов и других подходов в программировании
От: Sinix  
Дата: 06.08.14 08:38
Оценка: +2
Здравствуйте, Alllie, Вы писали:

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

+1000.

На мой взгляд, главная проблема с паттернами — в их переоценённости и в абсолютной оторванности от практики. Вот тут
Автор: XopoSHiy
Дата: 14.04.10
и тут
Автор: Геннадий Васильев
Дата: 23.05.11
это дело очень хорошо расписано. Ну и вот относительно свежая ветка
Автор: -rsdn-
Дата: 24.03.14
конкретно о .net и пост Сергея Теплякова
Автор: SergeyT.
Дата: 30.03.14
из неё.

В теории — да, паттерны должны экономить время за счёт использования типовых и проверенных решений. На практике — я ещё не видел ни одной книги/статьи/работы, посвящённой эффективному использованию классических паттернов (GoF/Фаулера) на практике, с учётом языка/фреймворка/проблем предметной области. Зато усилия по натягиванию паттернов на код и последствия я сам наблюдал и чинил неоднократно


Не, для c#, например, есть framework design guidelines, но она скорее о том, как НЕ использовать паттерны. С первых страниц:

Framework Design Principle
Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.


Ещё есть переложение Мартина на c#, но оно такое, что лучше бы и не было. Ув. Сергей Тепляков написал отзыв по книге, согласен от и до.


A>Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)?

A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?

А вот тут, на мой взгляд, лучше вообще не пытаться использовать паттерны как аргумент для выбора. Для отдельных решений ошибочно выбранный паттерн ещё можно исправить, а вот основу архитектуры лучше закладывать исходя из практических соображений. Смотреть на характер нагрузки, уровень команды, опыт похожих решений, используемый язык/фреймворк и т.д. и т.п. Абстрактных универсальных ответов тут нет и не может быть
Re[5]: Суть паттернов и других подходов в программировании
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.08.14 17:23
Оценка: +1 :)
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Ops, Вы писали:


Ops>>Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю


PD>Когда я первый раз прочитал про паттерны, я понял, что о них я знал еще тогда, когда не было паттернов


Господа, вы же профессионалы, просто достаньте линейки и померяйтесь.
Re[23]: Суть паттернов и других подходов в программировании
От: hi_octane Беларусь  
Дата: 10.08.14 11:00
Оценка: 15 (1)
>Насколько понимаю, там где $ это интерполяция через макрос. Нет возможности пример получше подобрать. Что делать, если подобный код должен стать асинхронным, скажем, надо что бы унутре строки была функция, которая возвращает асинхронный результат.

Имхо зря ты напираешь на преобразование синхронщины в асинхронщину. Это не одна, а две связанных задачи, одна из которых уже решена — в Nemerle даже беты были средства преобразования кода позволяющие построить из любого куска цепочку вложенных друг в друга продолжений. Дальше всё совсем легко, глядя одним глазом в существующие реализацию async/await вызывать нужную тебе функцию и выполнять её продолжение по завершении. Т.е. async/await из C# только без необходимости писать эти ключевые слова. Для функций которые не зависят друг от друга по данным, ты сам, уверен, сделаешь такой макрос глядя в доки и то что уже наработано. И он закроет примерно 80% сценариев. Но:

останется, как писал Эрик Липперт, ещё 80%: сделать так чтобы всё это работало без сильных глюков и давало какой-то профит. Ты сам называешь вторую часть задачи вот здесь:

I>Если имеем дело с чистым ДСЛ, то нет никаких проблем. А вот что делать с ЯОН ?


Вот тут есть проблема. При переводе _любой_ функции (как поставлена задача) в асинхронную — макросу поглупее придётся оборачивать в локи буквально каждый объект и вызов метода (и то не факт что будет работать), просто потому что преобразование функции в асинхронную как-бы подразумевает что она может быть вызвана несколько раз до своего завершения, может использовать и изменять состояние каких-то объектов, и это надо как-то согласованно менять. Макросу поумнее придётся строить граф вызовов и какими-то эвристиками решать где тут можно отделаться Interlocked, где заменять lock(this) на эквивалент работающий на пуле, а где рыбу заворачивали.

Между прочим в Nemerle эту вторую задачу решать в разы проще — именно из-за неизменяемости переменных и функционального стиля случаев когда макрос споткнётся о какую-то нетривиальную замену кода, или мутабельную переменную, минимизированы. Вплоть до того что можно просто лапки подвешивать и говорить что преобразование невозможно, как часто делает C# — ограничений на методы с преобразованиями кода целая куча — yield return и try/catch; lock и async; обломы с ref/out, и т.п.

Из-за того что само преобразование возможно, и его реализация лишь вопрос затраченных усилий, — прав WolfHound. Из-за того что конкретно это преобразование не только не реализовано, но ещё и сама реализация может легко выкатиться за человеко-год, без гарантий что всё будет работать на 100% кода, вроде как и ты тоже прав. И никогда вы не договоритесь
Re[2]: Суть паттернов и других подходов в программировании
От: Baudolino  
Дата: 06.08.14 08:59
Оценка: +1
S>На мой взгляд, главная проблема с паттернами — в их переоценённости и в абсолютной оторванности от практики.
Насчет переоцененности — да, а вот про оторванность — это какая-то ерунда. На практике они вполне применимы, потому и существуют.

S>В теории — да, паттерны должны экономить время за счёт использования типовых и проверенных решений. На практике — я ещё не видел ни одной книги/статьи/работы, посвящённой эффективному использованию классических паттернов (GoF/Фаулера) на практике, с учётом языка/фреймворка/проблем предметной области.

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

S>Зато усилия по натягиванию паттернов на код и последствия я сам наблюдал и чинил неоднократно

Хорошие архитекторы — большая редкость.
Re[2]: Суть паттернов и других подходов в программировании
От: Alllie  
Дата: 06.08.14 09:49
Оценка: +1
Здравствуйте, Sinix, Вы писали:

A>>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?

S>UPD 0x7be отлично ответил, про http://apparchguide.ms/ я что-то забыл

Книга хорошая, я ее читал. Вопрос в другом: большинство книг показывают некое решение, его свойства, НО не показывают проблемы и их свойства.
Эта книга не исключение, она описывает различные архитектуры и слои, но она не говорит, почему эти слои нужны.
То есть для того кто это сформулировал была такая последовательность:
1. Есть проблема.
2. Решаем эту проблему с помощью слоев приложения.
Книга дает читателю немного другую последовательность:
1. Есть такое решение, у него такие плюсы.

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


Вот если вспомнить уроки алгебры, то как они проходили?
1. Учитель пишет уравнение: (2 + 3)^2
2. Объясняет, что есть формула: (a + b)^2 = a^2 + 2ab + b^2
3. Показывает решение первого примера.
4. Потом вызывает пару учеников, что бы те применили эту формулу с измененными цифрами + с добавлением других примеров.
5. ПОтом задает домашнее задание и потом контрольная на которой ученики действуют так: вижу уравнение часть, которого похожа на формулу из п.2, буду применять эту формулу.

То есть с книжками по программированию как то не все пункты есть.
Re[4]: Суть паттернов и других подходов в программировании
От: Baudolino  
Дата: 06.08.14 09:54
Оценка: +1
Здравствуйте, Alllie, Вы писали:

B>>Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату.

A>Вот это уже интереснее, что за подход такой "системный и объектно-ориентированный анализ"?
Это не подход, а целая дисциплина для изучения. Подходы существуют разные, например, предметно-ориентированное проектирование (DDD, Domain-Driven Design).

A>Реально помогает принимать правильные решения?

Да.

A>И какие приемы, методики в рамках данного анализа существуют?

http://en.wikipedia.org/wiki/Systems_analysis
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design
http://en.wikipedia.org/wiki/Domain-driven_design
Покликайте по ссылкам в статьях, погуглите. Ответ на этот вопрос трудно дать в одном комментарии на форуме.

A>Применяли ли вы эти методы в практике?

Да, конечно.
Re[3]: Суть паттернов и других подходов в программировании
От: Ops Россия  
Дата: 06.08.14 12:30
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

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


Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[7]: Суть паттернов и других подходов в программировании
От: Ops Россия  
Дата: 06.08.14 13:15
Оценка: +1
Здравствуйте, LaptevVV, Вы писали:

LVV>

LVV>Вот! Похоже, что это именно тот порог, когда народ начинает понимать.
LVV>Если, конечно, народ реально работает...

Только казалось бы, при чем тут паттерны?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[4]: Суть паттернов и других подходов в программировании
От: Pavel Dvorkin Россия  
Дата: 06.08.14 14:38
Оценка: +1
Здравствуйте, Ops, Вы писали:

Ops>Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю


Когда я первый раз прочитал про паттерны, я понял, что о них я знал еще тогда, когда не было паттернов
With best regards
Pavel Dvorkin
Re[5]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 07.08.14 18:09
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

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


Как это следует из того что я написал не представляю.

Паттерн вызов метода
push значение_1
push значение_2
call procedure

переехал в компилятор в единственном экземпляре. И уже компилятором размножается по всей программе.

I>Правильно, потому что паттерны не имеют никакого отношения ни к компилятору, ни к библитеке. Это просто некоторые устойчивые образования, которые появляются в силу структурирования кода человеком или группой людей.

push значение_1
push значение_2
call procedure

Засунут в компилятор почти во всех языках программирования.

I>Как структурируешь код, такие паттерны там и появятся.

Для того чтобы у тебя в программе на C# появился показанный выше паттерн придётся ну очень постараться.

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

WH>>Если язык позволяет, то они устраняются методами языка.
WH>>Язык с метапрограммированием может устранить что угодно.

I>Да, я выше показал пример — "App.Run()"

Ты показал, что ты любишь съезжать с темы, когда начинаешь понимать, что слил.

I>Макры ничем не лучше. Рано или поздно появляется паттерн который никуда не всунуть.

Обосновать можешь?

I>Более того — с компилятором так же появляется паттерн, от которого не избавиться потому, что разрабы перестали развивать компилятор (хотя бы в одном из направлений).

С компилятором монолитных языков типа C# они гарантированно появляются в любом случае.

I>В DSL паттернов не меньше. Возьми DSL навроде SQL или RegExp — полно паттернов.

I>Более того, любой ДСЛ обладает таким свойством — например BNF имеет кучу паттернов.
А в них уже есть метапрограммирование?

WH>>К сожалению, в общем случае, это возможно только если есть метапрограммирование.

I>Особенно, если закрывать глаза на паттерны в библиотеке макров.
Нет там паттернов. От слова совсем.
Паттерн это повторяющейся с небольшими отличиями кусок кода.
В библиотеку макросов он уезжает в одном экземпляре.
И размножается уже компилятором во время компиляции программы.
Что там генерирует компилятор не важно.
Важно, что у нас в коде больше нет вот такой порнографии по всему коду.
push значение_1
push значение_2
call procedure
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 07.08.14 20:54
Оценка: +1
Здравствуйте, Alllie, Вы писали:

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

A>Про повторяющися код вы правы, он хорошо решается кодогенерацией, метапрограммированием, в том числе аспектно ориентированное программирование про тоже самое, но в этой ветки мы говорим про другое.
Нет никакого идеологически эффективного способа.
Это выдумка авторов книжек по паттернам, ибо им нужно эти книги продавать.
Ибо если бы они назывались честно "как писать повторяющейся код" то их никто бы не стал покупать.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[11]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 08.08.14 13:51
Оценка: :)
Здравствуйте, Ikemefula, Вы писали:

I> Я то думал, что строчки взяты чисто для демонстрации, а вы реализовали паттерны один в один "как в книге". При чем книга уже порядком устарела, за 20 лет.

Книга и 20 лет назад была бредом.

I>Вобщем, "новый" взгляд на паттерны — "строим приложение из паттернов"

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

Но в любом случае ты опять съехал с темы. Слив засчитан.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[14]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.14 16:34
Оценка: -1
Здравствуйте, WolfHound, Вы писали:

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

WH>Паттерн это повторяющейся код.
WH>Повторяющегося кода больше нет.
WH>Паттерна больше нет.

На вызывающей стороне всего лишь стало меньше кода. Ни одна из проблем майнтенанса не решена.

I>>2 Соответсвенно теперь разобраться стало на порядок сложнее, ибо мета-код сложнее простого кода. Вместо десятка строчек в описании класса появилось 20-30 строчек мета-кода в либе.

WH>Практика показывает, что это просто не правда.
WH>Ибо в реальности будет не десяток строк, а десятки строк в сотнях мест.

Это если целенаправленно копипастить, при чем буквально — копировал в клипборд, копировал из клипборда

Кроме того, любой паттерн можно локально оптимизировать десятком вариантов. В твоем случае это реализуемо только теоретически, за счет усложнения мета-кода.

I>>3 Даже глядя на реализацию паттернов, мета-код одного паттерна очень похож на мета-код другого паттерна.

WH>Сколько ещё раз нужно повторить, что это просто учебный пример?

В репе ровно обратное, скажем полно вот таких вещей

<[
      using (xxx = $(yyy))) 
      {
        { .. $pars_init };
        zzz;
      }
    ]>


Почему это не паттерн, не ясно

I>>Очевидно, если мета-кода будут мегабайты, то здесь сами собой нарисуются паттерны навроде "атрибут-ххх" или "квази-метод-yyy" или "мега-цикл-zzz".

WH>При реализации макросов можно использовать макросы.

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

I>>Теперь самый цимес — как сделать рефакторинг ну например стратегия->стейт->композит или наоборот ? В решарпере это небольшое количество шагов, в основном из кликов мышов и хоткеев. а у тебя ?

WH>Как я уже говорил в реальной жизни, реальные макросы пишутся под задачу.

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

WH>И в реальной жизни нужно поправить немного кода.

WH>И компилятор радостно размножит правку в сотнях экземплярах.

В реальности надо вводить согласованые изменения в разные участки кода, которые, внезапно, могут сворачиваться в более общие структуры. После изменения требований, что происходит постоянно, эти структуры трансформируются в совершенно разные вещи.
Выносить всю такую логику в мета-код и терять гибкость по моему как то странно
Re[6]: Суть паттернов и других подходов в программировании
От: ononim  
Дата: 08.08.14 19:22
Оценка: :)
Ops>>>Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю
PD>>Когда я первый раз прочитал про паттерны, я понял, что о них я знал еще тогда, когда не было паттернов
G>Господа, вы же профессионалы, просто достаньте линейки и померяйтесь.
Профессионалы пользуюся рулетками.
Как много веселых ребят, и все делают велосипед...
Re[3]: Суть паттернов и других подходов в программировании
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.08.14 08:19
Оценка: +1
Здравствуйте, artelk, Вы писали:
A>Имхо, не все паттерны удовлетворяют такому условию.
A>Facade, Mediator и Chain-of-responsibility — не ясно, что там можно устранить.
Ну, вот например реализация Фасада для COM сопряжена с некоторыми проблемами — это же частный случай Aggregation, с вытекающими обязанностями по отслеживанию reference counts.
B итоге фасад превращается в тонны boilerplate кода, который уныл, однообразен, и вся польза его — в возможности допустить ошибку.
А вот в Delphi есть встроенная в язык поддержка агрегации, называется, ЕМНИП, interface delegation.
То есть в нём изготовление фасада делается на раз-два:
property MyInterface: IMyInterface read FMyInterface implements IMyInterface
property MyInterface2: IMyInterface2 read FMyInterface2 implements IMyInterface2

И нам не нужно переписывать все 50 методов каждого интерфейса в наш фасад.

Если покопаться, то почти для всех паттернов можно найти устранимый boilerplate.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Суть паттернов и других подходов в программировании
От: Alllie  
Дата: 06.08.14 07:46
Оценка:
Первый вопрос: как находить суть паттернов?

Вопрос может и кажется простым, но все же я его раскрою более подробно.
Что такое паттерн? И суть паттерна? Для этого надо понять как появился паттерн. А появился он так: была какая то проблема у которой были определенные признаки, программист придумал какое то решение, которое уменьшало данную проблему это решение окозалось довольно эффективным для похожих проблем, проблем у которых есть схожие с исходной проблемой признаки. И вот со временем данное решение назвали паттерном, так как оно эффективно решает определенный тип проблем. Суть паттерна в том, что он в определенных условия (определенный тип проблемы) действует эффективно.

Почему появилось такое понятие как антипаттерн? Потому что люди прочитали про паттерн, запомнили как его применять, но не поняли, зачем именно он нужен. И вот применив паттерн в том месте, где его суть (те плюсы которые он дает), не особо дает каких то плюсов программе мы получаем антипаттерн.

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

Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)?

Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?
Re: Суть паттернов и других подходов в программировании
От: Sinix  
Дата: 06.08.14 08:46
Оценка:
Здравствуйте, Alllie, Вы писали:

A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?

UPD 0x7be отлично ответил, про http://apparchguide.ms/ я что-то забыл
Re[3]: Суть паттернов и других подходов в программировании
От: Sinix  
Дата: 06.08.14 09:13
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Насчет переоцененности — да, а вот про оторванность — это какая-то ерунда. На практике они вполне применимы, потому и существуют.

Ну... для явы пожалуй да. Фаулеровская класска во многом писалась с учётом возможностей/ограничений явы.

А вот GoF в переложении для c# выглядит очень странно, что ни решение — то дикий костыль. В примерах (pdf) большинство паттернов (навскидку — фабричный метод, ленивая инициализация, синглтон, наблюдатель и т.д.) — это скорее антипаттерны, т.к. на "чистом" c# то же самое делается проще и красивее. Обсуждали недавно, вот пример для билдера
Автор: Sinix
Дата: 28.03.14
.

S>>В теории — да, паттерны должны экономить время за счёт использования типовых и проверенных решений. На практике — я ещё не видел ни одной книги/статьи/работы, посвящённой эффективному использованию классических паттернов (GoF/Фаулера) на практике, с учётом языка/фреймворка/проблем предметной области.


B>Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату.

+1. Только справочник по сопромату я бы заменил на "Физику стартрека". Больше соответствует
Re[3]: Суть паттернов и других подходов в программировании
От: Alllie  
Дата: 06.08.14 09:20
Оценка:
Здравствуйте, Baudolino, Вы писали:

B>Таких книжек и не появится — они не нужны и даже опасны. Нужно изучать системный и объектно-ориентированный анализ в целом. Самостоятельно применять паттерны, прочитав только GoF, — это то же самое как проектировать многоэтажный дом, имея за плечами только справочник по сопромату.


Вот это уже интереснее, что за подход такой "системный и объектно-ориентированный анализ"? Реально помогает принимать правильные решения?
И какие приемы, методики в рамках данного анализа существуют?

Применяли ли вы эти методы в практике?
Re: Суть паттернов и других подходов в программировании
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 06.08.14 09:42
Оценка:
Здравствуйте, Alllie, Вы писали:

A>Первый вопрос: как находить суть паттернов?


A>Вопрос может и кажется простым, но все же я его раскрою более подробно.

A>Что такое паттерн? И суть паттерна? Для этого надо понять как появился паттерн. А появился он так: была какая то проблема у которой были определенные признаки, программист придумал какое то решение, которое уменьшало данную проблему это решение окозалось довольно эффективным для похожих проблем, проблем у которых есть схожие с исходной проблемой признаки. И вот со временем данное решение назвали паттерном, так как оно эффективно решает определенный тип проблем. Суть паттерна в том, что он в определенных условия (определенный тип проблемы) действует эффективно.

Суть паттерна в слабости языков и\или библиотек. В книге GOF описаны шаблоны проектирования, из которых добрая половина уже встроена в современные языки и библиотеки. То что не встроено — сводится к трем "базовым паттернам" — разделение отвественности, рекурсивная композиция, динамический полиморфизм. Причем реальная потребность применять такое на практике появляется крайне редко.

A>Почему появилось такое понятие как антипаттерн? Потому что люди прочитали про паттерн, запомнили как его применять, но не поняли, зачем именно он нужен. И вот применив паттерн в том месте, где его суть (те плюсы которые он дает), не особо дает каких то плюсов программе мы получаем антипаттерн.

Анти-паттерн это не только неэффективно примененный паттерн. Паттернов в коде найти много, например любой частоповторяемый кусок кода, написанный с одной целью можно назвать паттерном. У этого паттерна не обязательно должно быть эффективное применение. А если он приносит только вред, то будет называться антипаттерном. Например применение try с пустым catch можно назвать антипаттерном.

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

Кэп?

A>Второй вопрос: как соотнести то же самое к вопросам архитектуры приложения или вообще к другим областям? Какую архитектуру выбрать 3 звена (клиент, сервер, бд) или 2 звена (клиент, бд)?

A>Может есть какие то общие подходы? Как можно проанализировать, что выбрать? Листок бумаги + столбики плюсов и минусов для каждого варианта?

Чтобы правильно построить архитектуру — нужно анализировать потребности. Не требования, которые кто-то формально выдвигает, а именно реальные потребности пользователей\потребителей. В процессе анализа неэффективные решения отваливаются сами собой и остается обычно небольшое количество, которые обычно представляет выбор между "сделать быстро" и "сделать хорошо". В этом случае надо делать быстро. На следующей итерации может оказаться, что в процессе анализа не были учтены все факторы, поэтому код надо переписать.
Re[3]: Суть паттернов и других подходов в программировании
От: 0x7be СССР  
Дата: 06.08.14 10:20
Оценка:
Здравствуйте, Alllie, Вы писали:

A>То есть для того кто это сформулировал была такая последовательность:

A>1. Есть проблема.
A>2. Решаем эту проблему с помощью слоев приложения.
...
A>Тот кто это сформулировал в дальнейшем будет действовать так:
A>Вижу проблему, она похожа на ту, уоторую я хорошо решил с помощью слоев, давай и здесь я применю слои.
A>Тот кто прочитал книгу в дальнейшем будет действовать так:
A>Начинаю делать новый проект, а давай я применю слои, так как вот в это книге написано, что это круто.
В обоих этих сценариях не хватает очень важного момента: оценки выбранного архитектурного решения и коррекции изначального предположения.
Петли обратной связи. Если с этим всё хорошо, то можно начинать с произвольной архитектуры и через некоторое количество итераций она "сойдётся" к приемлемой.
Re[3]: Суть паттернов и других подходов в программировании
От: Sinix  
Дата: 06.08.14 10:24
Оценка:
Здравствуйте, Alllie, Вы писали:

A>Книга хорошая, я ее читал. Вопрос в другом: большинство книг показывают некое решение, его свойства, НО не показывают проблемы и их свойства.


Так appguide — не учебник. Он хорош как раз тем, что зная базовые требования, можно ограничиться парой-тройкой вариантов и дальше уже копать предметно, с привлечением людей с опытом по конкретной тематике.
Без опыта довольно тяжело оценить что важно, что нет. Иначе для описания всех крайних случаев потребуется не одна книга, причём для большинства проектов в этих книгах будет 0.99 воды и одна сотая — пара действительно полезных советов.

A>Эта книга не исключение, она описывает различные архитектуры и слои, но она не говорит, почему эти слои нужны.

На самом деле наличие/отсутствие отдельных слоёв (логика, данные, UI, etc) не особо зависит от выбранной архитектуры. Вопрос в соотношении: что разделить, что можно перекинуть на фреймворк, что придётся переписывать не раз (тут лучше подстелить соломку и не закладываться на текущее решение).
Re[2]: Суть паттернов и других подходов в программировании
От: LaptevVV Россия  
Дата: 06.08.14 12:16
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, Alllie, Вы писали:


Ops>Паттерны — это договор программистов о терминологии. Все.

Ни в коем случае!
Ops>Сами подходы, описываемые паттернами, довольно очевидны даже при небольшом опыте. И единственное применение им — правильно (и коротко) назвать свое решение, чтобы другие поняли.
При небольшом опыте — не очевидны.
Паттерн — типовое решение, инкапсулирующее возможные изменения кода — это в первую очередь.
Насчет небольшого опыта — конкретный пример.
Один мой студент — очень хороший студент — переписывал архитектуру приложения 6 (ШЕСТЬ) раз,
пока удалось приемлемое решение получить. На это у него ушло 3 года практически ежедневного труда...
Решение, позволяющее относительно безболезненно развивать систему, расширяя ее, а не изменяя.
Он признавался, что только набив вот этих шишек на собственной шкуре, наконец, понял, для чего нужны паттерны.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Суть паттернов и других подходов в программировании
От: LaptevVV Россия  
Дата: 06.08.14 12:45
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, LaptevVV, Вы писали:


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


Ops>Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю

И сколько опыта у вас тогда было?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[5]: Суть паттернов и других подходов в программировании
От: Ops Россия  
Дата: 06.08.14 13:07
Оценка:
Здравствуйте, LaptevVV, Вы писали:

LVV>И сколько опыта у вас тогда было?

Года 2-4, сейчас точно не помню.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[6]: Суть паттернов и других подходов в программировании
От: LaptevVV Россия  
Дата: 06.08.14 13:09
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, LaptevVV, Вы писали:


LVV>>И сколько опыта у вас тогда было?

Ops>Года 2-4, сейчас точно не помню.

Вот! Похоже, что это именно тот порог, когда народ начинает понимать.
Если, конечно, народ реально работает...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[8]: Суть паттернов и других подходов в программировании
От: LaptevVV Россия  
Дата: 06.08.14 13:20
Оценка:
Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, LaptevVV, Вы писали:


LVV>>

LVV>>Вот! Похоже, что это именно тот порог, когда народ начинает понимать.
LVV>>Если, конечно, народ реально работает...

Ops>Только казалось бы, при чем тут паттерны?

Дык общее развитие мозгов происходит жеж...
Вон Нимцович рекомендовал учиться играть в шахматы следующим образом:
— возьмите некоторое окончание (например, король с пешкой против короля) и досконально его изучите.
И вы с удивлением обнаружите, что стали гораздо лучше играть дебют и миттельшпиль — хотя специально этими темами не занимались.

А мой студент в результате переписывания как раз тотально паттерны и применил — ибо система нуждалась в непрерывном развитии.
Поэтому жизнь заставила...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 06.08.14 21:31
Оценка:
Здравствуйте, Alllie, Вы писали:

A>Первый вопрос: как находить суть паттернов?

Паттерн это копипаста неустранимая средствами выбранного языка.
В похожих языках (C# и Java) паттерны похожи. В сильно разных (C# и haskell) сильно разные.
В языках с качественным метапрограммированием найти паттерны не просто. Ибо трудно придумать копипасту которую не устранить метапрограммированием.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 07.08.14 13:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Вот так, что бы кода было много и весь на метапрограммировании, и не было паттернов — это в принципе невозможно. Любая более менее устойчивая структура будет паттерном. Например в языках с метапрограммированием паттерны нужно искать в библиотеках макросов. Понятно, что метапрограммирование не устраняет паттерны. Эти самые паттерны просто кочуют в библиотеки макросов и компилятор.

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

I>Вообще паттерны это естественный этап накопления опыта. Во всех без исключения областях деятельности человека есть эти самые паттерны. Скажем "сицилианская защита" в шахматах это обычный паттерн. Или например "королевский гамбит" это целое семейство паттернов.

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

I>Правильные вопросы про паттерны — как ими пользоваться и почему они собственно вознимают.

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

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

К сожалению, в общем случае, это возможно только если есть метапрограммирование.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[4]: Суть паттернов и других подходов в программировании
От: Alllie  
Дата: 07.08.14 14:11
Оценка:
Я имел ввиду паттерны программирования типа тех, которые описаны в GoF. А вы про какие говорите? Почему паттерн это копипаста? Копипаста организации кода? Приведите пример на каком нибудь языке программирование с метапрограммированием, как вы выполните определенную задачу для которой в обычном языке необхоимо применить некий паттерн. Самый распространенный (частой звучащее название) паттерн это фабрика, давайте на его примере.
Re[5]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 07.08.14 15:00
Оценка:
Здравствуйте, Alllie, Вы писали:

A>Я имел ввиду паттерны программирования типа тех, которые описаны в GoF. А вы про какие говорите?

Да про них и говорю.

A>Почему паттерн это копипаста? Копипаста организации кода? Приведите пример на каком нибудь языке программирование с метапрограммированием, как вы выполните определенную задачу для которой в обычном языке необхоимо применить некий паттерн. Самый распространенный (частой звучащее название) паттерн это фабрика, давайте на его примере.

Была куча почти одинакового кода:
class Factory 
{
  public virtual CreateWidget (name : string) : Widget {
    Widget (name)
  }
  public virtual CreateWorker (name : string, tasks : int) : Worker {
    Worker (name, tasks)
  }
}

class MyFactory : Factory 
{
  public override CreateWidget (name : string) : Widget {
    MyWidget (name)
  }
  public override CreateWorker (name : string, tasks : int) : Worker {
    MyWorker (name, tasks)
  }
}

Применили макрос и она исчезла.
[Nemerle.DesignPatterns.AbstractFactory (Widget, Worker)]
class Factory {}

[Nemerle.DesignPatterns.AbstractFactory (
  Override (MyWidget, Widget),
  Override (MyWorker, Worker)
)]
class MyFactory : Factory {}

https://github.com/rsdn/nemerle/wiki/Design-patterns

Но это абстрактная фабрика в вакууме. В реальности фабрики генерируются намного хитрее. А пользовательский код вообще не подозревает, что они есть.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re: Суть паттернов и других подходов в программировании
От: __kot2  
Дата: 07.08.14 16:12
Оценка:
Здравствуйте, Alllie, Вы писали:
A>Первый вопрос: как находить суть паттернов?
мне кажется, наиболее точный перевод слова паттерн в данном случае это узор.
вот вы смотрите снежинки падают. они все разные, но во многом похожи. В мозку у вас автоматом проходит процесс кластеризации данных и выявления их характеристик. вы замечаете, что бывают большие и маленькие, бывают, там, не знаю, с дыркой и без дырки. когда у вас накапливается статистика, вы даете знакомым узорам имена. то же самое с паттернами программирования. есть какие-то часто встречающиеся решения, которым логично дать некие термины. чтобы каждый не давал им свои имена и избежать путаницы, договорились об именах для подобных решений. антипаттерны — это просто имена для часто встречающихся хреновых решений.
Re[4]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.08.14 17:48
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Вот так, что бы кода было много и весь на метапрограммировании, и не было паттернов — это в принципе невозможно. Любая более менее устойчивая структура будет паттерном. Например в языках с метапрограммированием паттерны нужно искать в библиотеках макросов. Понятно, что метапрограммирование не устраняет паттерны. Эти самые паттерны просто кочуют в библиотеки макросов и компилятор.

WH>Ох. А сколько паттернов перекочевало в код компиляторов обычных языков, никогда не задумывался? Вызов метода паттерн. Вызов виртуального метода немного другой паттерн. Цикл снова паттерн. Итп.

WH>Если что-то уехало в библиотеку или компилятор, то это уже не паттерн.


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

WH>Ибо повторяющегося с маленькими отличиями куска кода больше нет.


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

В любом случае фокус — в приложении оставляем "DoAllApp.Run()" и, внезапно, весь код у нас в библиотеке. Следовательно паттернов там нет

I>>Вообще паттерны это естественный этап накопления опыта. Во всех без исключения областях деятельности человека есть эти самые паттерны. Скажем "сицилианская защита" в шахматах это обычный паттерн. Или например "королевский гамбит" это целое семейство паттернов.

WH>Не верная аналогия. В шахматах мы не можем засунуть паттерны в компилятор.

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

Как структурируешь код, такие паттерны там и появятся.

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

WH>Если язык позволяет, то они устраняются методами языка.
WH>Язык с метапрограммированием может устранить что угодно.

Да, я выше показал пример — "App.Run()"

WH>А вот у всех остальных языков рано или поздно встречается паттерн который ни в функцию ни в класс не засунуть.

WH>И такие паттерны начинают жить своей жизнью отравля жизнь разработчикам.

Макры ничем не лучше. Рано или поздно появляется паттерн который никуда не всунуть. Более того — с компилятором так же появляется паттерн, от которого не избавиться потому, что разрабы перестали развивать компилятор (хотя бы в одном из направлений).

I>>Правильные вопросы про паттерны — как ими пользоваться и почему они собственно вознимают.

WH>Возникают они из-за несоответствия выбранного языка и предметной области. Языки общего назначения, как правило, ничего общего с предметной областью не имеют. Вот на них паттерны и расцветают пышным цветом.

В DSL паттернов не меньше. Возьми DSL навроде SQL или RegExp — полно паттернов.
Более того, любой ДСЛ обладает таким свойством — например BNF имеет кучу паттернов.

WH>К сожалению, в общем случае, это возможно только если есть метапрограммирование.


Особенно, если закрывать глаза на паттерны в библиотеке макров.
Re[6]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.08.14 18:03
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Применили макрос и она исчезла.

WH>
WH>[Nemerle.DesignPatterns.AbstractFactory (Widget, Worker)]
WH>class Factory {}

WH>[Nemerle.DesignPatterns.AbstractFactory (
WH>  Override (MyWidget, Widget),
WH>  Override (MyWorker, Worker)
WH>)]
WH>class MyFactory : Factory {}
WH>


Не исчезла, а там где была там и осталась, только кода стало меньше. Зато теперь человек, который хочет понять этот код, должен неизвестно где рыться, что бы понять о чем речь. А если ему надо поменять стратегию инициализации, связывания и тд и тд, то и вовсе бедствие.
Re[7]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 07.08.14 18:26
Оценка:
Здравствуйте, Ikemefula, Вы писали:

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

Бедствие будет если этот код размножить в 100 раз и пойти менять его руками.
А вот когда у тебя все генерируется то всё просто.
Буквально вчера мне понадобилось сделать то, о чем ты говоришь.
В том куске кода, который я не видел, наверное, год. И его ещё и хардкейс весьма основательно перекопал.
Заработало всё с первой попытки.

И подобные изменения происходят регулярно.

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

Я описываю реальную практику применения метапрограммирования.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Суть паттернов и других подходов в программировании
От: Alllie  
Дата: 07.08.14 19:22
Оценка:
Не согласен.
Вот видите мы опять ушли от сути паттернов к их применению.
Ваш пример показывает другое применение паттерна фабрика, а мы говорили про суть, суть в том, что паттерн фабрика решает некоторую проблему. В этом случае я ожидал от вас код, в котором изначально есть проблема, а потом она решается метапрограммированием, без применения петтерна фабрика.


И вот опять же как все плохо описано в книгах и статьях, из википедии только кусок смог найти полезный. Хотя особо больше нигде и не искал.
Суть данного паттерна описывается здесь: http://en.wikipedia.org/wiki/Factory_(object-oriented_programming)#Applicability
Вся статья посвящена самому паттерну, то как его использовать, какие плюсы он дает, но только вот то что по ссылке, эти три пункта реально объясняют зачем он нужен.
Выберите пункт и предложите другое решение, которое не является паттерном.
Re[6]: Суть паттернов и других подходов в программировании
От: Alllie  
Дата: 07.08.14 19:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Нет там паттернов. От слова совсем.

WH>Паттерн это повторяющейся с небольшими отличиями кусок кода.
WH>В библиотеку макросов он уезжает в одном экземпляре.
WH>И размножается уже компилятором во время компиляции программы.
WH>Что там генерирует компилятор не важно.
WH>Важно, что у нас в коде больше нет вот такой порнографии по всему коду.
WH>
WH>push значение_1
WH>push значение_2
WH>call procedure
WH>


Мы все же про разные паттерны. Мы тут про те паттерны, не которые повторяющиеся куски кода, а про те, которые идеологически являются эффективным способом некой проблемы.
Про повторяющися код вы правы, он хорошо решается кодогенерацией, метапрограммированием, в том числе аспектно ориентированное программирование про тоже самое, но в этой ветки мы говорим про другое.
Re[8]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 07.08.14 21:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

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

WH>Бедствие будет если этот код размножить в 100 раз и пойти менять его руками.
WH>А вот когда у тебя все генерируется то всё просто.

Давай на секунду представим, что в код лезет человек, который читал не ту книгу по паттернам, и ему твоя AbstractFactory ни о чем не говорит.
Что он должен подумать про override(x, y) и тд ?
Re: Про суть
От: smeeld  
Дата: 07.08.14 21:06
Оценка:
Паттерн или нет?

#define container_of(ptr, type, member) ({                      \
          const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
          (type *)( (char *)__mptr - offsetof(type,member) );})
Re[9]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 07.08.14 21:50
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Давай на секунду представим, что в код лезет человек, который читал не ту книгу по паттернам, и ему твоя AbstractFactory ни о чем не говорит.

I>Что он должен подумать про override(x, y) и тд ?
То же самое что он сделает в случае с библиотекой.
Пойдёт читать документацию или исходники, если документации нет.
https://github.com/rsdn/nemerle/wiki/Design-patterns#abstract-factory-pattern
https://github.com/rsdn/nemerle/blob/master/macros/DesignPatterns.n#L78
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[8]: Суть паттернов и других подходов в программировании
От: Alllie  
Дата: 08.08.14 06:32
Оценка:
А ну тогда вообще ничего нет. Дизайн паттернов не существует, MVC/MVP/MVVM тоже не существует, трехзвенной/двухзвенной архитектуры тоже не существует.

Эти книги, все же не про копипасту текста, они про решение конкретных проблем, конкретными подходами.
Re[9]: Суть паттернов и других подходов в программировании
От: artelk  
Дата: 08.08.14 07:29
Оценка:
Здравствуйте, Alllie, Вы писали:

A>Эти книги, все же не про копипасту текста, они про решение конкретных проблем, конкретными подходами.


Конкретная проблема: передать параметры в процедуру.

Конкретный подход к решению: использовать системный стек.

Конкретное решение:

push значение_1
push значение_2
call procedure


Не?
Re[10]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.14 07:36
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Что он должен подумать про override(x, y) и тд ?

WH>То же самое что он сделает в случае с библиотекой.
WH>Пойдёт читать документацию или исходники, если документации нет.
WH>https://github.com/rsdn/nemerle/wiki/Design-patterns#abstract-factory-pattern
WH>https://github.com/rsdn/nemerle/blob/master/macros/DesignPatterns.n#L78

Я то думал, что строчки взяты чисто для демонстрации, а вы реализовали паттерны один в один "как в книге". При чем книга уже порядком устарела, за 20 лет.

Вобщем, "новый" взгляд на паттерны — "строим приложение из паттернов"
Re[10]: Суть паттернов и других подходов в программировании
От: Alllie  
Дата: 08.08.14 07:43
Оценка:
Здравствуйте, artelk, Вы писали:

A>Здравствуйте, Alllie, Вы писали:


A>>Эти книги, все же не про копипасту текста, они про решение конкретных проблем, конкретными подходами.


A>Конкретная проблема: передать параметры в процедуру.


A>Конкретный подход к решению: использовать системный стек.


A>Конкретное решение:


A>
A>push значение_1
A>push значение_2
A>call procedure
A>


A>Не?


Да, если так описывать и назвать это паттерном передачи параметров в в процедуру, то да. Можно же и в обратном порядке в стек складывать и в обратном, можно параметры передавать по ссылке, это все правильно. Но здесь мы все же про Design patterns.
Re[11]: Суть паттернов и других подходов в программировании
От: artelk  
Дата: 08.08.14 08:04
Оценка:
Здравствуйте, Alllie, Вы писали:

A>Да, если так описывать и назвать это паттерном передачи параметров в в процедуру, то да. Можно же и в обратном порядке в стек складывать и в обратном, можно параметры передавать по ссылке, это все правильно. Но здесь мы все же про Design patterns.


Вызов процедур с передачей параметров — основной паттерн процедурного программирования.

Еще пример: в C# есть event'ы (на основе делегатов). Без них пришлось бы каждый раз вручную педалить паттерн Наблюдатель. Т.е. паттерн встроили в язык, предотвратив километры копипасты.
Re[12]: Суть паттернов и других подходов в программировании
От: Vaako Украина  
Дата: 08.08.14 14:19
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Ikemefula, Вы писали:


I>> Я то думал, что строчки взяты чисто для демонстрации, а вы реализовали паттерны один в один "как в книге". При чем книга уже порядком устарела, за 20 лет.

WH>Книга и 20 лет назад была бредом.

I>>Вобщем, "новый" взгляд на паттерны — "строим приложение из паттернов"

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

WH>Но в любом случае ты опять съехал с темы. Слив засчитан.


Не надоело вам про паттерны спорить?
Каждый месяц одно и то же.
У каждого свои паттерны и это их неустранимая спеифика
Re[12]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.14 14:30
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>> Я то думал, что строчки взяты чисто для демонстрации, а вы реализовали паттерны один в один "как в книге". При чем книга уже порядком устарела, за 20 лет.

WH>Книга и 20 лет назад была бредом.

Весь это устаревший бред ты перетянул в либу

WH>Но в любом случае ты опять съехал с темы. Слив засчитан.


1 Ты сам показал, что паттерны никуда не делись, только перекочевали в либу и превратились в мета-код.
2 Соответсвенно теперь разобраться стало на порядок сложнее, ибо мета-код сложнее простого кода. Вместо десятка строчек в описании класса появилось 20-30 строчек мета-кода в либе.

3 Даже глядя на реализацию паттернов, мета-код одного паттерна очень похож на мета-код другого паттерна. Очевидно, если мета-кода будут мегабайты, то здесь сами собой нарисуются паттерны навроде "атрибут-ххх" или "квази-метод-yyy" или "мега-цикл-zzz".

Вобщем ты сделал за меня всю работу

Теперь самый цимес — как сделать рефакторинг ну например стратегия->стейт->композит или наоборот ? В решарпере это небольшое количество шагов, в основном из кликов мышов и хоткеев. а у тебя ?
Re[12]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.14 14:35
Оценка:
Здравствуйте, artelk, Вы писали:

A>Еще пример: в C# есть event'ы (на основе делегатов). Без них пришлось бы каждый раз вручную педалить паттерн Наблюдатель. Т.е. паттерн встроили в язык, предотвратив километры копипасты.


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

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

Нет способа избавиться от паттернов. Есть способ сделать код понятным и экономически эффективным.
Re[13]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 08.08.14 15:02
Оценка:
Здравствуйте, Vaako, Вы писали:

V>Не надоело вам про паттерны спорить?

V>Каждый месяц одно и то же.
V>У каждого свои паттерны и это их неустранимая спеифика
Специфика паттернов в том, что они сами устранимы.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 08.08.14 15:02
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Весь это устаревший бред ты перетянул в либу

Не я.
Это просто примеры простых макросов не более того.

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

Паттерн это повторяющейся код.
Повторяющегося кода больше нет.
Паттерна больше нет.

I>2 Соответсвенно теперь разобраться стало на порядок сложнее, ибо мета-код сложнее простого кода. Вместо десятка строчек в описании класса появилось 20-30 строчек мета-кода в либе.

Практика показывает, что это просто не правда.
Ибо в реальности будет не десяток строк, а десятки строк в сотнях мест.

I>3 Даже глядя на реализацию паттернов, мета-код одного паттерна очень похож на мета-код другого паттерна.

Сколько ещё раз нужно повторить, что это просто учебный пример?

I>Очевидно, если мета-кода будут мегабайты, то здесь сами собой нарисуются паттерны навроде "атрибут-ххх" или "квази-метод-yyy" или "мега-цикл-zzz".

При реализации макросов можно использовать макросы.

I>Теперь самый цимес — как сделать рефакторинг ну например стратегия->стейт->композит или наоборот ? В решарпере это небольшое количество шагов, в основном из кликов мышов и хоткеев. а у тебя ?

Как я уже говорил в реальной жизни, реальные макросы пишутся под задачу.
И в реальной жизни нужно поправить немного кода.
И компилятор радостно размножит правку в сотнях экземплярах.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[13]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 08.08.14 15:05
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Более того — добавив в язык эвенты, получили весь набор паттернов на этих эвентах.

I>Если и их устранить, меняя язык, то с каждой новой фичей будем получать паттерны на ней основаные.

I>Паттерн есть просто идиома, которая существует в силу того, что много людей структурируют код руководствуясь примерно одними и теми же соображениями.

И происходит это из-за несоответствия языка решаемой задаче.

I>Нет способа избавиться от паттернов. Есть способ сделать код понятным и экономически эффективным.

Ты только что сам его показал. См выделенное.
Имея макросы, каждый может менять язык до тех пор, пока паттернов не останется.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[7]: Суть паттернов и других подходов в программировании
От: hi_octane Беларусь  
Дата: 08.08.14 15:17
Оценка:
A>В этом случае я ожидал от вас код, в котором изначально есть проблема, а потом она решается метапрограммированием, без применения петтерна фабрика.
Вот для этого надо при помощи метапрограммирования переопределить создание объекта так чтобы объект создавался через фабрику даже если пользователь пишет (в Nemerle new нету, так что для простоты на C#):

[ContextFactory]
internal FA
{
   public A Create()
   {
     .....
   }
}

[Factory(FA)]
public class A
{

}

//использование:
var a = new A();//реально будет подставлено Context.FA.Create()


теперь смотри на код с точки зрени потребителя: вызывается конструктор объекта, объект создаётся, всё просто и понятно. То что там под капотом фабрика, которая выбирается исходя из контекста — это всё ушло. Для потребителя — фабрики нету. Также как у потребителя foreach (тоже пример метапрограммирования), в голове нету GetEnumerator()/MoveNext()/Current и т.п.

P.S. Ну а если глубже смотреть — то сама необходимость в паттерне "фабрика" в .NET языках вызвана тем что в CLR есть объекты, и их надо как-то создавать.
Re[5]: Суть паттернов и других подходов в программировании
От: Sinclair Россия https://github.com/evilguest/
Дата: 08.08.14 15:23
Оценка:
Здравствуйте, Alllie, Вы писали:

A>Я имел ввиду паттерны программирования типа тех, которые описаны в GoF. А вы про какие говорите? Почему паттерн это копипаста? Копипаста организации кода? Приведите пример на каком нибудь языке программирование с метапрограммированием, как вы выполните определенную задачу для которой в обычном языке необхоимо применить некий паттерн. Самый распространенный (частой звучащее название) паттерн это фабрика, давайте на его примере.

Отличный пример. Вот, например, в языке Delphi паттерн "фабрика" не встречается никогда.
Потому, что в язык встроены понятия "class type" и "виртуальный конструктор".
Если я объявил класс TMyButton с конструктором Create, унаследованный от TControl, то я могу передать ссылку на этот класс в любой код, который ожидает ссылку на TControlClass. И этот код сможет порождать мои кнопки, вызывая конструктор Create через эту ссылку.

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

На языке с метапрограммированием мы бы имели то же самое, только без хардкода в компиляторе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[9]: Суть паттернов и других подходов в программировании
От: hi_octane Беларусь  
Дата: 08.08.14 15:38
Оценка:
A>А ну тогда вообще ничего нет. Дизайн паттернов не существует, MVC/MVP/MVVM тоже не существует, трехзвенной/двухзвенной архитектуры тоже не существует.

Вся изоляция кода в слои или объекты "отвечающие" за свою часть работы, нужна только людям чтобы меньше путаться. Если бы были средства выражения понятий "эти поля связаны, в базе менять только транзакцией, в многопоточнй среде только под lock" — зачем трёхзвенная архитектура?

A>Эти книги, все же не про копипасту текста, они про решение конкретных проблем, конкретными подходами.


Немного самонадеянно и я конечно рискую слиться, но давай сюда конкретную проблему с конкретным подходом, и попытаемся её выразить через метапрограммирование так чтобы уши паттерна снаружи не торчали
Re[14]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.14 16:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Паттерн есть просто идиома, которая существует в силу того, что много людей структурируют код руководствуясь примерно одними и теми же соображениями.

WH>И происходит это из-за несоответствия языка решаемой задаче.

Структурировать приходится не потому, что язык не тот, а потому, что информации слишком много. Небольшие изменения часто приводят к тому, что структура решения меняется очень сильно.
Например код, внезапно, который был серверным, должен стать клиентским. Или наоборот — часть кода клиента должна мигрировать на сервер или вовсе въехать в БД.

WH>Имея макросы, каждый может менять язык до тех пор, пока паттернов не останется.


В обмен на усложение за счет мета-кода, отсутствия рефакторинга и, как следствие, запрета регулярных, постоянных изменений в требованиях ?
Re[15]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 08.08.14 17:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Структурировать приходится не потому, что язык не тот, а потому, что информации слишком много. Небольшие изменения часто приводят к тому, что структура решения меняется очень сильно.

И для этого метакод идеален.

I>Например код, внезапно, который был серверным, должен стать клиентским. Или наоборот — часть кода клиента должна мигрировать на сервер или вовсе въехать в БД.

Подпилить метакод в таких случаях очень просто.

WH>>Имея макросы, каждый может менять язык до тех пор, пока паттернов не останется.

I>В обмен на усложение за счет мета-кода, отсутствия рефакторинга и, как следствие, запрета регулярных, постоянных изменений в требованиях ?
Метакод даёт прямо противоположный эффект.
Ты разговариваешь с человеком, который последние 2 года пишет в основном метакод.
Для меня все, что ты тут говоришь просто смешно.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[15]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 08.08.14 17:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

WH>>Паттерн это повторяющейся код.

WH>>Повторяющегося кода больше нет.
WH>>Паттерна больше нет.
I>На вызывающей стороне всего лишь стало меньше кода. Ни одна из проблем майнтенанса не решена.
Копипаста исчезла?
Да.
Проблемы связанные с копипастой исчезли?
Да.

I>Это если целенаправленно копипастить, при чем буквально — копировал в клипборд, копировал из клипборда



I>Кроме того, любой паттерн можно локально оптимизировать десятком вариантов. В твоем случае это реализуемо только теоретически, за счет усложнения мета-кода.

Оптимизируй это
    // This is a simple customer class that 
    // implements the IPropertyChange interface.
    public class DemoCustomer : INotifyPropertyChanged
    {
        // These fields hold the values for the public properties.
        private Guid idValue = Guid.NewGuid();
        private string customerNameValue = String.Empty;
        private string phoneNumberValue = String.Empty;

        public event PropertyChangedEventHandler PropertyChanged;

        // This method is called by the Set accessor of each property.
        // The CallerMemberName attribute that is applied to the optional propertyName
        // parameter causes the property name of the caller to be substituted as an argument.
        private void NotifyPropertyChanged([CallerMemberName] String propertyName = "")
        {
            if (PropertyChanged != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
        }

        // The constructor is private to enforce the factory pattern.
        private DemoCustomer()
        {
            customerNameValue = "Customer";
            phoneNumberValue = "(312)555-0100";
        }

        // This is the public factory method.
        public static DemoCustomer CreateNewCustomer()
        {
            return new DemoCustomer();
        }

        // This property represents an ID, suitable
        // for use as a primary key in a database.
        public Guid ID
        {
            get
            {
                return this.idValue;
            }
        }

        public string CustomerName
        {
            get
            {
                return this.customerNameValue;
            }

            set
            {
                if (value != this.customerNameValue)
                {
                    this.customerNameValue = value;
                    NotifyPropertyChanged("CustomerName");
                }
            }
        }

        public string PhoneNumber
        {
            get
            {
                return this.phoneNumberValue;
            }

            set
            {
                if (value != this.phoneNumberValue)
                {
                    this.phoneNumberValue = value;
                    NotifyPropertyChanged("PhoneNumber");
                }
            }
        }
    }

С макросами это будет так
    // This is a simple customer class that 
    // implements the IPropertyChange interface.
    [ImplementNotifyPropertyChanged]
    public class DemoCustomer : INotifyPropertyChanged
    {
        // These fields hold the values for the public properties.
        private Guid idValue = Guid.NewGuid();

        // The constructor is private to enforce the factory pattern.
        private DemoCustomer()
        {
            CustomerNameValue = "Customer";
            PhoneNumberValue = "(312)555-0100";
        }

        // This is the public factory method.
        public static DemoCustomer CreateNewCustomer()
        {
            return new DemoCustomer();
        }

        // This property represents an ID, suitable
        // for use as a primary key in a database.
        public Guid ID
        {
            get
            {
                return this.idValue;
            }
        }

        public string CustomerName { get; set; default String.Empty; }
        public string PhoneNumber { get; set; default String.Empty; }
    }

Теперь добавь ещё десяток свойств. Помножь на пару десятков классов.
Потом порефакторь.
Не забудь отследить, что в NotifyPropertyChanged всегда передаётся строка, соответствующая имени свойства.

I>В репе ровно обратное, скажем полно вот таких вещей

I>
I><[
I>      using (xxx = $(yyy))) 
I>      {
I>        { .. $pars_init };
I>        zzz;
I>      }
I>    ]>
I>

I>Почему это не паттерн, не ясно
Этого наезда вообще не понял.
Что ты тут хочешь сэкономить?

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

Макросы меняют язык.

I>В реальности надо вводить согласованые изменения в разные участки кода, которые, внезапно, могут сворачиваться в более общие структуры. После изменения требований, что происходит постоянно, эти структуры трансформируются в совершенно разные вещи.

С метакодом ты на этой задаче упаришься гоняться.

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

Ты метакод вообще писал?
Ибо с точки зрения человека, который его действительно писал, ты несёшь полный бред.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.14 19:10
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>На вызывающей стороне всего лишь стало меньше кода. Ни одна из проблем майнтенанса не решена.

WH>Копипаста исчезла?
WH>Да.
WH>Проблемы связанные с копипастой исчезли?
WH>Да.

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

I>>Кроме того, любой паттерн можно локально оптимизировать десятком вариантов. В твоем случае это реализуемо только теоретически, за счет усложнения мета-кода.

WH>Теперь добавь ещё десяток свойств. Помножь на пару десятков классов.
WH>Потом порефакторь.

см пример ниже.

WH>Не забудь отследить, что в NotifyPropertyChanged всегда передаётся строка, соответствующая имени свойства.


Это давно уже решено

I>>В репе ровно обратное, скажем полно вот таких вещей

I>>
I>><[
I>>      using (xxx = $(yyy))) 
I>>      {
I>>        { .. $pars_init };
I>>        zzz;
I>>      }
I>>    ]>
I>>

I>>Почему это не паттерн, не ясно
WH>Этого наезда вообще не понял.
WH>Что ты тут хочешь сэкономить?

Я утверждаю, что это паттерн мета-кода, которому пока что еще не дали названия за немногочисленностью коммюнити.

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

WH>Макросы меняют язык.

Linq уже внятно поддерживается или как ?

I>>В реальности надо вводить согласованые изменения в разные участки кода, которые, внезапно, могут сворачиваться в более общие структуры. После изменения требований, что происходит постоянно, эти структуры трансформируются в совершенно разные вещи.

WH>С метакодом ты на этой задаче упаришься гоняться.

Ога. Вот представь у тебя есть некоторый АПИ. Ну хоть и та моделька, что ты показал.
И ты его заюзал во всем приложении. Само собой, все это упрятано в макросы всех сортов — ты же именно этот подход проповедуешь ?

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

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

WH>Ты метакод вообще писал?

Разумеется.

WH>Ибо с точки зрения человека, который его действительно писал, ты несёшь полный бред.


Ты уже в который раз за два дня переходишь на личности и пытаешься обсуждать квалификацию. За последние лет 8 я уже привык
Re[16]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 08.08.14 19:17
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Структурировать приходится не потому, что язык не тот, а потому, что информации слишком много. Небольшие изменения часто приводят к тому, что структура решения меняется очень сильно.

WH>И для этого метакод идеален.

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

I>>Например код, внезапно, который был серверным, должен стать клиентским. Или наоборот — часть кода клиента должна мигрировать на сервер или вовсе въехать в БД.

WH>Подпилить метакод в таких случаях очень просто.

Не ясно, что такое "просто", в каких единицах это мерять ?

I>>В обмен на усложение за счет мета-кода, отсутствия рефакторинга и, как следствие, запрета регулярных, постоянных изменений в требованиях ?

WH>Метакод даёт прямо противоположный эффект.

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

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


А ты знаешь, что такие фразы это ни разу не аргумент ? Сам подумай — такое может написать практически любой.
Re[17]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 08.08.14 19:54
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ты наверное сравниваешь копипасту с её отсутствием А я вообще говорю про внятный дизайн vs макры.

INotifyPropertyChanged это невнятный дизацн?

I>Если, скажем, ты заюзал паттерн Синглтон и упрятал внутренности поглубже, основная проблема с Синглтоном в том, что это фактически глобальная переменная, доступная из разных мест.

I>Независимо от того, где находятся внутренности, проблема глобальной переменной остаётся чего бы ты не делал.
Опять с темы съезжаешь.
Причём тут вообще глобальные переменные?

WH>>Теперь добавь ещё десяток свойств. Помножь на пару десятков классов.

WH>>Потом порефакторь.
I>см пример ниже.
Что смотреть?

WH>>Не забудь отследить, что в NotifyPropertyChanged всегда передаётся строка, соответствующая имени свойства.

I>Это давно уже решено
Как?

I>Я утверждаю, что это паттерн мета-кода, которому пока что еще не дали названия за немногочисленностью коммюнити.

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

I>Linq уже внятно поддерживается или как ?

Не знаю. Я им не пользуюсь.

I>Теперь фокус — этот апи в силу требований становится асинхронным. Твоя задача — переписать весь код, который завязан на эту хрень, вплоть до самого верхнего уровня.

Я регулярно подобным занимаюсь.
Но из-за того что у меня всё на ДСЛях никаких проблем не возникает.
В любом случае тебе придётся проделать минимум на порядок больше работы чем мне.

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

WH>>Ты метакод вообще писал?
I>Разумеется.
Не верю. Ибо иначе не нёс бы бред.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 08.08.14 20:14
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Покажи как синхронную модель превратить в асинхронную, и весь вызывающий код независимо от глубины вложенности и тд и тд так же превратить в асинхронный.

У меня изначально ничего на это завязано не будет.
И клиенты ДСЛя просто ничего не заметят.
С парсером я такое уже не один раз проделывал.

I>Не ясно, что такое "просто", в каких единицах это мерять ?

В строчках кода.

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

I>А ты знаешь, что такие фразы это ни разу не аргумент ? Сам подумай — такое может написать практически любой.
Не соврав мало кто может.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.14 06:37
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Покажи как синхронную модель превратить в асинхронную, и весь вызывающий код независимо от глубины вложенности и тд и тд так же превратить в асинхронный.

WH>У меня изначально ничего на это завязано не будет.

Это не аргумент. Выдай формулу с помощью которой любой девелопер, даже студент сможет повторить такой вот фокус.

Вот у меня есть код
return x.f();


Внезапно, он становится асинхронным. Теперь любая функция, которая его вызывает, становится асинхронной и так до самого верха.

I>>Не ясно, что такое "просто", в каких единицах это мерять ?

WH>В строчках кода.

Строчки кода к простоте не имеют отношения. Если ты не согласен, то без труда скажешь, что это за алгоритм
f =: (] #~ [: +/ =/) i.@(>./)


Я вот думаю, что простоту надо мерять по целевой аудитории. Если большинству понятно, значит это действительно просто.
Re[18]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.14 06:52
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Ты наверное сравниваешь копипасту с её отсутствием А я вообще говорю про внятный дизайн vs макры.

WH>INotifyPropertyChanged это невнятный дизацн?

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

I>>Независимо от того, где находятся внутренности, проблема глобальной переменной остаётся чего бы ты не делал.

WH>Опять с темы съезжаешь.
WH>Причём тут вообще глобальные переменные?

На примере макры Синглтон. Независимо от размера кода самого синглтона, 10 строчек кода на реализацию или 20, проблемы находятся в вызывающем коде.

Ты предлагаешь забить на эти проблемы и сделать код синглтона короче. У меня вот некоторые синглтоны вызываются по 1000 и более раз (>50мб кода). Это значит, что количеством кода самого класса, какой бы вариант для синглтона не был выбран, можно тупо пренебречь.

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

WH>>>Не забудь отследить, что в NotifyPropertyChanged всегда передаётся строка, соответствующая имени свойства.

I>>Это давно уже решено
WH>Как?

Имя свойства в C# уже "само" приходит. Ты же сам вроде показал.

I>>Я утверждаю, что это паттерн мета-кода, которому пока что еще не дали названия за немногочисленностью коммюнити.

WH>Я утверждаю, что ты утверждаешь бред.
WH>На весь репозиторий я насчитал аж 4 применения этого паттерна.

Копипаста !!!

WH>Причем что тут можно сократить вообще не ясно.


Ты же сам сказал, что копипасту надо прятать.

I>>Linq уже внятно поддерживается или как ?

WH>Не знаю. Я им не пользуюсь.

 linq <# код запроса #>


вот от этого в немерле уже избавились или как ?

I>>Теперь фокус — этот апи в силу требований становится асинхронным. Твоя задача — переписать весь код, который завязан на эту хрень, вплоть до самого верхнего уровня.

WH>Я регулярно подобным занимаюсь.
WH>Но из-за того что у меня всё на ДСЛях никаких проблем не возникает.
WH>В любом случае тебе придётся проделать минимум на порядок больше работы чем мне.

То есть, ничего кроме общих слов.

I>>Разумеется.

WH>Не верю. Ибо иначе не нёс бы бред.

см выше
Re[15]: Суть паттернов и других подходов в программировании
От: Vaako Украина  
Дата: 09.08.14 11:30
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, WolfHound, Вы писали:


I>В реальности надо вводить согласованые изменения в разные участки кода, которые, внезапно, могут сворачиваться в более общие структуры. После изменения требований, что происходит постоянно, эти структуры трансформируются в совершенно разные вещи.



Вы так написали что чувствуется системный подход. Вы случайно не знакомы с какими-любо средствами разработки, которые такие согласованные изменения могут наглядно представлять и контролировать?
Re[16]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.14 14:34
Оценка:
Здравствуйте, Vaako, Вы писали:

V>Вы так написали что чувствуется системный подход. Вы случайно не знакомы с какими-любо средствами разработки, которые такие согласованные изменения могут наглядно представлять и контролировать?


Более менее внятные вещи есть только для статически типизированых языков. Например http://www.ndepend.com/, но этого мало, обязательно нужен внятный инструмент для рефакторинга и внятный декомпилер. Скажем, большую часть информации проще и эффективнее искать прямо в бинарниках.

Проблема возникает с проектами, которые состоят из нескольких солюшнов или же написаны на разных языках или есть злоупотребление разными динамическими фичами, тайп-касты, виртуальные методы или вовсе оголтелая динамика.
Чем больше такого разнообразия, тем сложнее контролировать зависимости.
Re[19]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 09.08.14 18:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>У меня без макров кода примерно столько, как у тебя с макрами. Мне, скажем, незачем выжимать такты процессора для интерактивных сцериев. Оптимизирую я для своих конкретных случаев и очевидно это не такты процессора.

Ты код то покажи. Вот мой если выкинуть всё что к делу не относится.
    [ImplementNotifyPropertyChanged]
    public class DemoCustomer : INotifyPropertyChanged
    {
        public string CustomerName { get; set; default String.Empty; }
        public string PhoneNumber { get; set; default String.Empty; }
    }


I>На примере макры Синглтон. Независимо от размера кода самого синглтона, 10 строчек кода на реализацию или 20, проблемы находятся в вызывающем коде.

А у меня синглитонов нет совсем.
Ни одного.

Все статические переменные содержат исключительно неизменяемые данные, определяемые на этапе компиляции.

I>Ты предлагаешь забить на эти проблемы и сделать код синглтона короче. У меня вот некоторые синглтоны вызываются по 1000 и более раз (>50мб кода). Это значит, что количеством кода самого класса, какой бы вариант для синглтона не был выбран, можно тупо пренебречь.

Когда все на ДСЛях то обе стороны генерируется.
И мне нужно поправить код в двух метах.

I>Зато имеет значение, как избавляться от этих синглтонов. И здесь это не так просто, как кажется. Каждый случай использования нужно обрабатывать руками, общего решения нет и быть не может.

Их изначально не должно быть.

I>Имя свойства в C# уже "само" приходит. Ты же сам вроде показал.

Где?

I>>>Я утверждаю, что это паттерн мета-кода, которому пока что еще не дали названия за немногочисленностью коммюнити.

WH>>Я утверждаю, что ты утверждаешь бред.
WH>>На весь репозиторий я насчитал аж 4 применения этого паттерна.
I>Копипаста !!!
Посчитай количество кода типа в своём проекте.
foreach (xxx in yyy)
{
  zzz
}


WH>>Причем что тут можно сократить вообще не ясно.

I>Ты же сам сказал, что копипасту надо прятать.
Ну, так ты и показал код, который затащил всю копипасту в себя.

I>
I> linq <# код запроса #>
I>

I>вот от этого в немерле уже избавились или как ?
А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.

I>То есть, ничего кроме общих слов.

Есть. А вот у тебя только бла-бла-бла.
https://github.com/JetBrains/Nitra

I>>>Разумеется.

WH>>Не верю. Ибо иначе не нёс бы бред.
I>см выше
Что выше? Ты ни одного примера своей работы с метапрограммированием не привёл.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 09.08.14 18:06
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Внезапно, он становится асинхронным. Теперь любая функция, которая его вызывает, становится асинхронной и так до самого верха.

Я вежливо попрошу компилятор сделать все, что нужно асинхронным.
А ты посадишь десяток студентов превращать 10 метров кода в 100.

I>>>Не ясно, что такое "просто", в каких единицах это мерять ?

WH>>В строчках кода.
I>Строчки кода к простоте не имеют отношения. Если ты не согласен, то без труда скажешь, что это за алгоритм
Ты ещё предложи код заархивировать. И на основе того что сжатый код вообще читать нельзя попробуй доказать свою правоту.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.14 18:46
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>Внезапно, он становится асинхронным. Теперь любая функция, которая его вызывает, становится асинхронной и так до самого верха.

WH>Я вежливо попрошу компилятор сделать все, что нужно асинхронным.
WH>А ты посадишь десяток студентов превращать 10 метров кода в 100.

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

I>>>>Не ясно, что такое "просто", в каких единицах это мерять ?

WH>>>В строчках кода.
I>>Строчки кода к простоте не имеют отношения. Если ты не согласен, то без труда скажешь, что это за алгоритм
WH>Ты ещё предложи код заархивировать. И на основе того что сжатый код вообще читать нельзя попробуй доказать свою правоту.

Итого твоя трактовка простоты снова сломалась
Re[21]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 09.08.14 19:13
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>То есть, никаких подробностей от тебя нет.

Есть. Просто ты читать не умеешь.

А вообще нужно перестать с тобой разговаривать, ибо ничего интересного я от тебя ни разу не услышал.
Один трёп про то, что ты в глаза не видел.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.14 19:47
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>То есть, никаких подробностей от тебя нет.

WH>Есть. Просто ты читать не умеешь.

"вежливо попрошу компилятор"

Это оно ?

WH>А вообще нужно перестать с тобой разговаривать, ибо ничего интересного я от тебя ни разу не услышал.

WH>Один трёп про то, что ты в глаза не видел.

см выше
Re[22]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.14 20:04
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>То есть, никаких подробностей от тебя нет.

WH>Есть. Просто ты читать не умеешь.

На всякий, еще раз про асинхронщину
 public GenerateMigration(path : string, ns : string) : void
    {
        def date = DateTime.Now.ToString("yyyyMMddhhmmss");
        def migrationName = $"M$(date).n";
        def text = ClassGenerator().GenerateMigration(ns, migrationName, migrationUsingsList);
        File.WriteAllText(Path.Combine(path, migrationName), text);
    }


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

Мне очень интересно посмотреть, как твои макросы помогут забороть вызывающий код.

Если имеем дело с чистым ДСЛ, то нет никаких проблем. А вот что делать с ЯОН ?
Валяй.
Re[6]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.14 20:16
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Потому, что в язык встроены понятия "class type" и "виртуальный конструктор".

S>Если я объявил класс TMyButton с конструктором Create, унаследованный от TControl, то я могу передать ссылку на этот класс в любой код, который ожидает ссылку на TControlClass. И этот код сможет порождать мои кнопки, вызывая конструктор Create через эту ссылку.

Это плохой пример. Фабрика это довольно устойчивая модель и внутри достаточно простая. Нет никакой проблемы с макросами.
С любой устойчивой моделью будет ровно то же.

Вопрос в том, как быть, когда модель меняется постоянно, то уезжает частями на сервер, то в бд, то еще куда нибудь.

Язык разумеется ЯОН, а не ДСЛ-всемогутор.

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

Непонятно, как быть с макросами. Я вот всерьёз считаю, что восстанавливать детали реализации из метакода занятие малоперспективное. Вот скажем неделю назад я несколько дней листал репозиторий через вебморду частично с телефона, частично с ипада. Весь генерированый текст под носом. Собтсвенно генерация делается только там, где без неё не обойтись, т.е. нужно описать неизвестное заранее количество сущностей.
Посмотрел шаблон, посмотрел где какие функции чего делают, и все вобщем понятно.

Как это повторить, если все детали спрятаны в мета-коде макроса, совершенно непонятно.

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

В простых случаях, навроде интерполяции строк, генерации сущностей для некоторой устойчивой модели, все понятно. Но вот чем дальше, тем все тухлее.
Как быть с преобразованием синхронного кода в асинхронный и обратно ?
Вроде как самое то для макросов. Но вот непонятно, как сорганизовать код, что бы все необходимое было в макросах.
Re[20]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 09.08.14 20:39
Оценка:
Здравствуйте, WolfHound, Вы писали:

I>>У меня без макров кода примерно столько, как у тебя с макрами. Мне, скажем, незачем выжимать такты процессора для интерактивных сцериев. Оптимизирую я для своих конкретных случаев и очевидно это не такты процессора.

WH>Ты код то покажи. Вот мой если выкинуть всё что к делу не относится.
WH>
WH>    [ImplementNotifyPropertyChanged]
WH>    public class DemoCustomer : INotifyPropertyChanged
WH>    {
WH>        public string CustomerName { get; set; default String.Empty; }
WH>        public string PhoneNumber { get; set; default String.Empty; }
WH>    }
WH>


Чего ты не унимаешься ? Я вроде как сказал, что для стабильных моделей макросы вполне себе годятся. Конкретно в моём случае T4 шаблон.
1 детали реализации проще отследить
2 весь код в репе, отсюда все мыслимые и немыслимые тулы умеют работать с этим искаропки

I>>На примере макры Синглтон. Независимо от размера кода самого синглтона, 10 строчек кода на реализацию или 20, проблемы находятся в вызывающем коде.

WH>А у меня синглитонов нет совсем.
WH>Ни одного.

Это не ответ. Мы про макрос Синглтон, а не про твой подход к дизайну.

I>>Ты предлагаешь забить на эти проблемы и сделать код синглтона короче. У меня вот некоторые синглтоны вызываются по 1000 и более раз (>50мб кода). Это значит, что количеством кода самого класса, какой бы вариант для синглтона не был выбран, можно тупо пренебречь.

WH>Когда все на ДСЛях то обе стороны генерируется.

Ты наверное хочешь, но стесняешься сказать примерно такое
1 — кроме макров надо поменять парадигму, использовать чтото навроде language oriented programming или dsl oriented programming
2 — вместо ЯОН нужен расширяемый ДСЛ-всемогутор
3 — нужен внятный дизайн

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

Если все на расширяемом ДСЛ то как бы вопросов нет. Вопрос в том, что будет с макросами в ЯОН.

I>>Зато имеет значение, как избавляться от этих синглтонов. И здесь это не так просто, как кажется. Каждый случай использования нужно обрабатывать руками, общего решения нет и быть не может.

WH>Их изначально не должно быть.

То есть, в кратце, макры здесь ничем не помогают ?

I>>Имя свойства в C# уже "само" приходит. Ты же сам вроде показал.

WH>Где?

Атрибут перед именем переменной '[CallerMemberName]' в твоём коде


I>>Копипаста !!!

WH>Посчитай количество кода типа в своём проекте.
WH>
WH>foreach (xxx in yyy)
WH>{
WH>  zzz
WH>}
WH>


Такой код почти везде, что тебя смущает ?

I>>вот от этого в немерле уже избавились или как ?

WH>А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.

То есть, это то о чем я говорил — язык перестает развиваться не смотря ни на что. Сколько лет уже ждут Nemerle 2 ?

I>>То есть, ничего кроме общих слов.

WH>Есть. А вот у тебя только бла-бла-бла.
WH>https://github.com/JetBrains/Nitra

Это не ответ. С таким же успехом ты можешь дать ссылку на библию или собрание сочинений Ленина.

I>>см выше

WH>Что выше? Ты ни одного примера своей работы с метапрограммированием не привёл.

Правильно, это ведь ты рассказываешь про некий мифический профит, но стесняешься придумать один нормальный пример — скоро десять лет одно и то же твердишь.
Re[6]: Суть паттернов и других подходов в программировании
От: Геннадий Васильев Россия http://www.livejournal.com/users/gesha_x
Дата: 09.08.14 21:44
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Применили макрос и она исчезла.

[Nemerle.DesignPatterns.AbstractFactory (Widget, Worker)]


Один только я вижу здесь паттерн Facade?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[20]: Суть паттернов и других подходов в программировании
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.08.14 21:58
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.

Не в обиду, но я от тебя лет 5 минимум слышу, что вот, почти завтра, в немерле следующей версии все будет круто, и вообще порвет в катяхи c#. И метапрограммирование станет полезным и доступным каждому.
Вот только это «завтра» никак не наступает, по большому за 5 лет ничего не изменилось и вряд ли изменится. Слишком сильно он отстал. Не как язык, а как идея.
Re[21]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 09.08.14 22:22
Оценка:
Здравствуйте, gandjustas, Вы писали:

WH>>А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.

G>Не в обиду, но я от тебя лет 5 минимум слышу, что вот, почти завтра, в немерле следующей версии все будет круто, и вообще порвет в катяхи c#. И метапрограммирование станет полезным и доступным каждому.
Он и сейчас рвёт C#.
И сейчас метапрограммирование проще чем где бы то ни было.
Просто будет ещё проще.

G>Вот только это «завтра» никак не наступает, по большому за 5 лет ничего не изменилось и вряд ли изменится.

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

G>Слишком сильно он отстал. Не как язык, а как идея.

От кого отстал? Имя сестра. Имя!
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[22]: Суть паттернов и других подходов в программировании
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 09.08.14 22:53
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, gandjustas, Вы писали:


WH>>>А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.

G>>Не в обиду, но я от тебя лет 5 минимум слышу, что вот, почти завтра, в немерле следующей версии все будет круто, и вообще порвет в катяхи c#. И метапрограммирование станет полезным и доступным каждому.
WH>Он и сейчас рвёт C#.
Разве в nemerle есть async? Или есть razor? Даже linq нормального нет.

WH>И сейчас метапрограммирование проще чем где бы то ни было.

WH>Просто будет ещё проще.
Это лишь слова. Покажи в сравнении с roslyn. Немерле2 покачто фантастика, а roslyn уже реален. Просто возьми примеры от roslyn и сравни. И не банальщину типа INotifyPropertyChanged или генерацию классов по внешним метаданным, потому что эта проблема в C# уже решена.

G>>Вот только это «завтра» никак не наступает, по большому за 5 лет ничего не изменилось и вряд ли изменится.

WH>То, что ты не видишь, не значит, что ничего не изменилось.
Для меня ничего не изменилось, при этом я активно мониторю ситуацию. А 99% остальных вообще насрать на немерле.

G>>Слишком сильно он отстал. Не как язык, а как идея.

WH>От кого отстал? Имя сестра. Имя!
От текущей реальности отстал. Уже тонны кода написаны на java, c# и даже f# с его typeprovider. Тысячи практических задач решены. Не сможет метапрограммирование в немерле дать что-нибудь полезное.
Re[23]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 09.08.14 23:25
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Разве в nemerle есть async?

Есть. И не один. Причём появились ещё до того как оно появилось в C#.

G>Или есть razor?

Есть круче.

G>Даже linq нормального нет.

Ну да... то что нужно написать linq<# #> это конечно большая беда.

G>Это лишь слова. Покажи в сравнении с roslyn. Немерле2 покачто фантастика, а roslyn уже реален.

roslyn тоже ещё фантастика.

G>Просто возьми примеры от roslyn и сравни. И не банальщину типа INotifyPropertyChanged или генерацию классов по внешним метаданным, потому что эта проблема в C# уже решена.

И что конкретно ты хочешь увидеть?

G>Для меня ничего не изменилось, при этом я активно мониторю ситуацию. А 99% остальных вообще насрать на немерле.

Не верю. Иначе бы знал и про async и про Nemerle.Web.

G>От текущей реальности отстал. Уже тонны кода написаны на java, c# и даже f# с его typeprovider. Тысячи практических задач решены. Не сможет метапрограммирование в немерле дать что-нибудь полезное.

Тем кто его реально использует, даёт. А вы всё не даёт да не даёт.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[23]: Суть паттернов и других подходов в программировании
От: hi_octane Беларусь  
Дата: 10.08.14 11:10
Оценка:
G>Разве в nemerle есть async? Или есть razor? Даже linq нормального нет.

Примеры разных async-ов появились наверное в 2010-м. И их можно свободно менять под задачу, в отличии от прибитых гвоздями реализаций в C#.
Re[2]: Про суть
От: Abyx Россия  
Дата: 10.08.14 12:23
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Паттерн или нет?


S>
S>#define container_of(ptr, type, member) ({                      \
S>          const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
S>          (type *)( (char *)__mptr - offsetof(type,member) );})
S>


Сишный говнокод.
In Zen We Trust
Re[24]: Суть паттернов и других подходов в программировании
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.08.14 12:50
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, gandjustas, Вы писали:


G>>Разве в nemerle есть async?

WH>Есть. И не один. Причём появились ещё до того как оно появилось в C#.
И всем крайне далеко до C#.
Необходимо чтобы умело работать с тасками.
Необходимо чтобы синтаксический оверхед был на уровне не выше C#, то есть два ключевых слова.
Увы такого в nemerle нет и не будет.

G>>Или есть razor?

WH>Есть круче.
Не круче. Все что есть это поделка на уровне WebSharper. Все такие поделки имеют два критических недостатка: а) сложно готовый html (реальный, а не 3 строки из примеров) переделать в такой шаблон б) композиция шаблонов делается через код жопу.


G>>Даже linq нормального нет.

WH>Ну да... то что нужно написать linq<# #> это конечно большая беда.
Огромная. Только она одна делает nemerle неюзабельным для практических задач.

G>>Это лишь слова. Покажи в сравнении с roslyn. Немерле2 покачто фантастика, а roslyn уже реален.

WH>roslyn тоже ещё фантастика.
Да ладно? Ты не обратил внимание что в ASP.NET MVC 5 используется roslyn для компиляции razor?
Так что реальность, причем более чем Nemerle.

G>>Просто возьми примеры от roslyn и сравни. И не банальщину типа INotifyPropertyChanged или генерацию классов по внешним метаданным, потому что эта проблема в C# уже решена.

WH>И что конкретно ты хочешь увидеть?
Что-нибудь значительно улучшающее процесс разработки без заметного геморроя для программистов.
Вот Синклер приводил пример про иерархию метаклассов в Delphi, повторить такое на Nemerle.
Или еще одна фишка, которая может упростить жизнь разработчикам библиотек — нечто похожее на variadic templates в C++, чтобы удобно и красиво делать варируемое число параметров функции с обработкой на этапе компиляии.

G>>Для меня ничего не изменилось, при этом я активно мониторю ситуацию. А 99% остальных вообще насрать на немерле.

WH>Не верю. Иначе бы знал и про async и про Nemerle.Web.
Я знаю, и знаю что это отстой. Для реального применения в разы хуже того что есть в C#.

G>>От текущей реальности отстал. Уже тонны кода написаны на java, c# и даже f# с его typeprovider. Тысячи практических задач решены. Не сможет метапрограммирование в немерле дать что-нибудь полезное.

WH>Тем кто его реально использует, даёт. А вы всё не даёт да не даёт.
Ну да, всем четырем человекам, которые реально используют может что-нибудь и дает. Прости, но даже F# побольше дает.
Re[24]: Суть паттернов и других подходов в программировании
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.08.14 12:52
Оценка:
Здравствуйте, hi_octane, Вы писали:

G>>Разве в nemerle есть async? Или есть razor? Даже linq нормального нет.


_>Примеры разных async-ов появились наверное в 2010-м. И их можно свободно менять под задачу, в отличии от прибитых гвоздями реализаций в C#.


Да-да, слизанные с F# 1-в-1. Только async в F# несмотря на мощность используется довольно слабым спросом, а async в C# используют почти все.
Re[25]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 10.08.14 17:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>И всем крайне далеко до C#.

G>Необходимо чтобы умело работать с тасками.
G>Необходимо чтобы синтаксический оверхед был на уровне не выше C#, то есть два ключевых слова.
G>Увы такого в nemerle нет и не будет.
Ну, зачем же врать то?
https://github.com/rsdn/nemerle/blob/master/snippets/Nemerle.Async/WindowsFormsTest/MainForm.n

G>>>Или есть razor?

WH>>Есть круче.
G>Не круче. Все что есть это поделка на уровне WebSharper.
Они не имеют между собой ничего общего.
WebSharper серверный шаблонизатор.
NemerleWeb клиентский GUI.

G>Все такие поделки имеют два критических недостатка: а) сложно готовый html (реальный, а не 3 строки из примеров) переделать в такой шаблон

Это сложно? Лично я вижу разор с точность до синтаксиса.
  [Html]
  View() : string
  {
    <#
      <div>
        Title
        <input value="$(TaskToAdd.Title)" />
        Priority
        <select value="$(TaskToAdd.Priority)">
          <option value="0">low</option>
          <option value="1">kinda important</option>
          <option value="2">really hungry!</option>
        </select>
        <button click="$AddTask">Add task</button>
        <ul>
          <li $foreach(t in Tasks.OrderByDescending(t => t.Priority))>
            $(t.Title) ($(t.Priority))
            <input type="checkbox" checked="$(t.Status)" />
          </li>
        </ul>
      </div>
    #>
  }



G>б) композиция шаблонов делается через код жопу.

Что?

G>Что-нибудь значительно улучшающее процесс разработки без заметного геморроя для программистов.

G>Вот Синклер приводил пример про иерархию метаклассов в Delphi, повторить такое на Nemerle.
Это не сложно. Но зачем?

G>Или еще одна фишка, которая может упростить жизнь разработчикам библиотек — нечто похожее на variadic templates в C++, чтобы удобно и красиво делать варируемое число параметров функции с обработкой на этапе компиляии.

В реальности это костыли для недометапрограммирования. В немерле нормальное есть.

G>Я знаю, и знаю что это отстой. Для реального применения в разы хуже того что есть в C#.

Не знаешь.

G>Ну да, всем четырем человекам, которые реально используют может что-нибудь и дает. Прости, но даже F# побольше дает.

... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[26]: Суть паттернов и других подходов в программировании
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.08.14 18:26
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, gandjustas, Вы писали:


G>>И всем крайне далеко до C#.

G>>Необходимо чтобы умело работать с тасками.
G>>Необходимо чтобы синтаксический оверхед был на уровне не выше C#, то есть два ключевых слова.
G>>Увы такого в nemerle нет и не будет.
WH>Ну, зачем же врать то?
WH>https://github.com/rsdn/nemerle/blob/master/snippets/Nemerle.Async/WindowsFormsTest/MainForm.n
Сорри, это как раз и пропустил. А зачем еще способы нужны?

G>>>>Или есть razor?

WH>>>Есть круче.
G>>Не круче. Все что есть это поделка на уровне WebSharper.
WH>Они не имеют между собой ничего общего.
WH>WebSharper серверный шаблонизатор.
WH>NemerleWeb клиентский GUI.
Эта фраза ни о чем.

G>>Все такие поделки имеют два критических недостатка: а) сложно готовый html (реальный, а не 3 строки из примеров) переделать в такой шаблон

WH>Это сложно? Лично я вижу разор с точность до синтаксиса.
WH>
WH>  [Html]
WH>  View() : string
WH>  {
WH>    <#
WH>      <div>
WH>        Title
WH>        <input value="$(TaskToAdd.Title)" />
WH>        Priority
WH>        <select value="$(TaskToAdd.Priority)">
WH>          <option value="0">low</option>
WH>          <option value="1">kinda important</option>
WH>          <option value="2">really hungry!</option>
WH>        </select>
WH>        <button click="$AddTask">Add task</button>
WH>        <ul>
WH>          <li $foreach(t in Tasks.OrderByDescending(t => t.Priority))>
WH>            $(t.Title) ($(t.Priority))
WH>            <input type="checkbox" checked="$(t.Status)" />
WH>          </li>
WH>        </ul>
WH>      </div>
WH>    #>
WH>  }
WH>

0) Выражения внутри тегов это жесть
1) Куда это вписывать? В код контроллера?
2) Как делается композиция?
3) Как делаются хелперы?



G>>б) композиция шаблонов делается через код жопу.

WH>Что?
То что прочитал

G>>Что-нибудь значительно улучшающее процесс разработки без заметного геморроя для программистов.

G>>Вот Синклер приводил пример про иерархию метаклассов в Delphi, повторить такое на Nemerle.
WH>Это не сложно. Но зачем?
Не реже раза в месяц появляется вопрос на эту тему в форуме по .NET.

G>>Или еще одна фишка, которая может упростить жизнь разработчикам библиотек — нечто похожее на variadic templates в C++, чтобы удобно и красиво делать варируемое число параметров функции с обработкой на этапе компиляии.

WH>В реальности это костыли для недометапрограммирования. В немерле нормальное есть.
Покажи пример, а то снова та же песня: вроде все есть, только по факту никто не использует.
Re[27]: Суть паттернов и других подходов в программировании
От: WolfHound  
Дата: 10.08.14 20:31
Оценка:
Здравствуйте, gandjustas, Вы писали:

WH>>WebSharper серверный шаблонизатор.

WH>>NemerleWeb клиентский GUI.
G>Эта фраза ни о чем.
Думаю, прежде чем вообще продолжать разговор тебе нужно понять, о чём эта фраза.
http://www.nemerleweb.com/tutorial

G>0) Выражения внутри тегов это жесть

И чего такого?

G>1) Куда это вписывать? В код контроллера?

Думаю, тебе всё же стоит разобраться с тем, о чём ты вообще говоришь.

G>2) Как делается композиция?

http://www.nemerleweb.com/tutorial#Templates

G>3) Как делаются хелперы?

Что?

G>Не реже раза в месяц появляется вопрос на эту тему в форуме по .NET.

Не знаю как сейчас, но раньше там и про деструктры вопросы появлялись.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[2]: Суть паттернов и других подходов в программировании
От: artelk  
Дата: 12.08.14 17:12
Оценка:
Здравствуйте, WolfHound, Вы писали:

WH>Паттерн это копипаста неустранимая средствами выбранного языка.

WH>В похожих языках (C# и Java) паттерны похожи. В сильно разных (C# и haskell) сильно разные.
WH>В языках с качественным метапрограммированием найти паттерны не просто. Ибо трудно придумать копипасту которую не устранить метапрограммированием.

Имхо, не все паттерны удовлетворяют такому условию.
Facade, Mediator и Chain-of-responsibility — не ясно, что там можно устранить.
Re[8]: Суть паттернов и других подходов в программировании
От: dimgel Россия https://github.com/dimgel
Дата: 13.08.14 20:59
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>В C# не нужнен паттерн "Publisher/Subscriber", потому что есть языковые понятия event и delegate.


Всё-таки мне думается, ты смешиваешь понятие "паттерн" (который суть чистая идея, абстракция) и "реализация паттерна". В твоём примере event/delegate — реализация паттерна publisher/subscriber на конкретном языке. Принципиально нет никакой разницы, реализован паттерн средствами языка, DSL или библиотеки; разница только в удобстве использования.
Re[24]: Суть паттернов и других подходов в программировании
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.08.14 13:59
Оценка:
Здравствуйте, hi_octane, Вы писали:

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


_>Имхо зря ты напираешь на преобразование синхронщины в асинхронщину.

...
>И он закроет примерно 80% сценариев.



I>>Если имеем дело с чистым ДСЛ, то нет никаких проблем. А вот что делать с ЯОН ?


_>Вот тут есть проблема. При переводе _любой_ функции (как поставлена задача) в асинхронную — макросу поглупее придётся оборачивать в локи


Локи и прочее, что ты указал, это только один из вариантов. В кратце — макросам придется думать, как обслуживать состояние, потому что на ровном месте образуются разделямые ресурсы и соответствующие конфликты.

Теоретически, решение есть — надо взять да и реализовать на макросах сущности навроде монад типа Future, Stream, State, обеспечить внятную ленивость, хитрые лифтинги и тд.
Я боюсь даже оценить сложность полученного решения.

_>Между прочим в Nemerle эту вторую задачу решать в разы проще — именно из-за


Я боюсь, что это "проще" неизмеримо, ибо должной квалификацией в макрах обладают единицы


_>Из-за того что само преобразование возможно, и его реализация лишь вопрос затраченных усилий, — прав WolfHound.


"возможно" наглядно демонстрируется разными компиляторами. Это как бы очевидно и совсем не понятно, почему WH повторяет это из года в год. Я говорю именно о сложности решения.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.