Реализация паттерна Visitor в Axapta

[Андре]

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

PHP код:

        void visit(Employee empl)
        {

        Boss boss;
        ;
        totalDays += empl.getVacDays();
        if (classIdGet(empl) == classNum(Boss))
        {

        boss = empl;
        totalDays += boss.getBonusDays(); }

        } 


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

Роль Класс
Посетитель(Visitor) Visitor
Конкретный посетитель(Concrete Visitor) VacationVisitor
Конкретный элемент (Concrete Element) Employee, Boss

[belugin]

PHP код:

if (classIdGet(empl) == classNum(Boss)) 


-->

PHP код:

SysDictClass::isEqualOrSuperclass(classIdGet(empl),classNum(Boss)) 


еще можно попробовать вынести этот код в макрос типа:

PHP код:

#localmacro.process
    if(SysDictClass::isEqualOrSuperclass(classIdGet(empl),classNum(%1))
    {
        this.visit_%1(empl);
    }
#endmacro 


и тогда

PHP код:

void visit(Employee empl)
{
   #process(Boss)
   #process(TinyMan)
}
void visit_Boss(Boss boss)
{ ...
}
void visit_TinyMan(TinyMan man)
{ ...
} 


[Андре]

Цитата:

isEqualOrSuperclass

Не - здесь по смыслу нужен именно isEqual, для SuperClass может своя логика реализовываться. Можно конечно добавить свой метод isEqual - но там идея будет таже самая - сравнение id:

PHP код:

   if (_id == _potentialAncestorId)
return true; 


Насчет макросов - красиво. Но я стараюсь их избегать, так как они противоречат ООП. Кроме того, где-то читал, что в будующих версиях от них попробуют отказаться.

[belugin]

Цитата:

Изначально опубликовано Андре
[B]
Не - здесь по смыслу нужен именно isEqual, для SuperClass может своя логика реализовываться.

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

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

Цитата:

Насчет макросов - красиво. Но я стараюсь их избегать

даже в pack unpack

[Андре]

Цитата:

.... это нехорошо, так как вводит лишнюю зависимость.

Согласен. Спасибо.

Цитата:

даже в pack unpack

Тут уж никуда не денешься

[mazzy]

Спасибо за отличный пример и за отличную ссылку.