Visitor vs. Reflection

← →
Alkid © (2007-10-23 15:09) [40]

> Любой алгоритм должен быть реализован минимальным количеством
> строк ясного кода
> (с)

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

Я сам переболел этим (к счастью без серзёного ущерба для кого-либо). А, вот, на моём текущем месте работы недавно уволился архитектор, по милости которого фирма вбухала огромные средства во Framework, который в итоге оказался неприспособлен для решения реальных задач.

← →
Kolan © (2007-10-23 15:09) [41]

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

Это GRASP паттерны, прочесть можно в Craig_Larman_Applying_UML_and_patterns_SE.djvu.
Да это не такие паттерны как GoF :). Ты их все и так знаешь, просто не знаешь их названий&#133

← →
Anatoly Podgoretsky © (2007-10-23 15:11) [42]

> Учусь печатать вслепую :)

Мне смена пришла, навались.

← →
Kolan © (2007-10-23 15:13) [43]

> Мне смена пришла, навались.

o_0?

PS
Ну развели же топиков про клавы, вот я и купил Microsoft 4000, а на ней не вслепую почти невозможно набирать&#133 Вот учусъ :)

← →
reonid © (2007-10-23 15:36) [44]

>Не скажи. Один проход может занимать некоторое время.
>Одновременно может совершаться проход по одному дереву
>несколькими statefull-visitor`ами. Как реализовать такой
>независимый проход на виртуальных функциях самих
>классов в принципе понятно, но будет коряво.

Визитор имеет две основные цели:
1) Обход дерева
2) Добавление произвольного количества полиморфных
операций к фиксированной иерархии.

и дополнительная цель
3) Хранение некоего контекста операции.

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

В твоём случае, насколько я понимаю, именно
второго пункта-то и нет, а нужны 1й и 3й пункты.

Я правильно понял ситуацию?

← →
Игорь Шевченко © (2007-10-23 15:44) [45]

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

Все этим болеют. Некоторые даже от этого умирают :)

← →
Alkid © (2007-10-23 15:49) [46]

> Все этим болеют. Некоторые даже от этого умирают :)

Ну вот наш бывший Chief Architect ушёл разваливать бизнес к конкурентам :)

← →
Alkid © (2007-10-23 15:53) [47]

> В твоём случае, насколько я понимаю, именно
> второго пункта-то и нет, а нужны 1й и 3й пункты.
>
> Я правильно понял ситуацию?

Да, именно так.
Там ближе к началу я описывал задачу: интерпретатор абстрактного синтаксического дерева LISP-подобного DSL.

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

← →
Anatoly Podgoretsky © (2007-10-23 15:59) [48]

> Kolan (23.10.2007 15:13:43) [43]

Правильно, не в слепую шея заболит.

← →
Anatoly Podgoretsky © (2007-10-23 15:59) [49]

> Alkid (23.10.2007 15:49:46) [46]

Ушел?
А может засланный казачок?

← →
Alkid © (2007-10-23 16:03) [50]

> Ушел?
> А может засланный казачок?

Точнее его "ушли". Для засланного он слишком долго тут работал - практически с основания фирмы. Просто
1. Он очень трудный в общении человек, с которым никому не хотелось тут работать.
2. Он убедил в своё время руководство вложиться в ненужный проект, который в итоге не достиг заявленных целей. А на него было потрачего ОЧЕНЬ много времени и денег.

В итоге его остранили от руководства и он уволился.

← →
Kolan © (2007-10-23 16:06) [51]

> Alkid

Раскрой таки тайну, какие точки вариации ты видишь в своей архитектуре, от этого и в прям совет сильно зависит. см. [44] reonid © (23.10.07 15:36)

← →
Alkid © (2007-10-23 16:08) [52]

> Раскрой таки тайну, какие точки вариации ты видишь в своей
> архитектуре, от этого и в прям совет сильно зависит. см.
> [44] reonid © (23.10.07 15:36)

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

← →
reonid © (2007-10-23 16:09) [53]

>Alkid © (23.10.07 15:53) [47]
>Да, именно так.

Тогда подумай, действительно ли тебе нужна двойная диспетчеризация?
Отдели то, что тебе нужно в Визиторе, от того, что тебе не нужно.

← →
Kolan © (2007-10-23 16:17) [54]

> Наиболее вероятное  расширение количества типов узлов дерева,
>

Имхо тогда с посетителем ты проиграешь, так как тебе придётся перекрывать много методов к какждом новом потомке.

← →
Kolan © (2007-10-23 16:20) [55]

«+» посетителя в легком добавлении новых посетителей: «Паттерн посетитель позволяет определить новую операцию, не изменяя
классы этих объектов».

А у тебя набор посетителей фиксированый&#133

← →
Alkid © (2007-10-23 16:29) [56]

Ок, коли такая пьянка пошла, абстрагируемся от визитора.
Надо сделать интерпретатор программы, подаваемой на вход в виде AST.
Интерпретатору так же в некотором виде подаются вхдные данные. Кроме того, он сохраняет в себе контекст выполнения.

Условия:
1. Несколько интерпретаторов одновременно могут вычислять одно и тоже дерево, т.е. они с деревом должны работать строго в режиме read-only и все состояни сохранять у себя.
2. Интерпретатор должен поддерживать неполное вычисление, т.е. вычислить, например, 1 узел, сохранить результат и вернуть управление. Потом, по следующему вызову, вычислить ещё кусочек и снова вернуться. Если ему достаточно много давали работать он в итоге вычисляет всю программу и возвращает результат.

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

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

Визитор был одной из опций, его и начали обсуждать

← →
Kolan © (2007-10-23 17:04) [57]

Хз, судя по примеру из GoF посетитель  приемлимое решенеие&#133
&#133Но если у вас
«Набор классов элементов дерева может расширяться и это будет шатной»
то имхо это точка вариации и вам надо думать как бы попроше именно это делать. Желательно вообще без перекомпиляции

> то имхо это точка вариации и вам надо думать как бы попроше
> именно это делать. Желательно вообще без перекомпиляции

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

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

> нет обработчика - это ситуация вскроется при сборке проекта.

а вот и непрада, ибо противоречит твоему же высказыванию их [7]

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

ты уж определись

> ты уж определись

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

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

> Посмотри на R#

Что это и где можно посмотреть?

Visitor vs. Reflection Найти похожие ветки