Как в методе базового класса перечислить классы потомки

Добрый день,
как в методе базового класса перечислить классы-наследники и создать их экземпляры?

Хочу провести эксперимент с методом construct.
Обычно в этом методе происходит анализ некого контекста (например поступившей на вход таблицы или енума) и по итогам этого анализа создается экземпляр нужного наследника.
Если мы допилили еще одного наследника, приходится допиливать и construct в базовом классе.
А что если возложить бремя анализа на самих наследников и в constuct опрашивать их на предмет того, нравится ли им текущий контекст, согласны ли они поработать.

P.S. Наследников наследников тоже хотелось бы перечислить.

[AndyD]

DictClass.extendedBy() - и работать со списком.
У найденных классов, соответственно, так же дергать extendedBy()

Вот только, овчинка выделки не стоит, имха

[sukhanchik]

Штатно, имеются 2 способа.
1. Берем список всех классов (класс Dictionary, методы classCnt, classCnt2Id), перебираем их в цикле и смотрим на свойство extends. Если оно указывает на наш класс - значит это наследник. Если не на наш - значит пропускаем. Соответственно - сделав тут рекурсию - мы получим список наследников и наследников наследников.
Скорость работы п.1 хорошо заметна - когда мы создаем новый Shared Project. Система ищет всех наследников класса ProjectNode и список наследников выводит в качестве пунктов меню. И это еще без наследников наследников. Само собой - речь идет о первой попытке создания Shared Project после входа в АХ. Затем это кешируется.

2. Иерархия объектов (пункт меню из контекстного меню Надстройки из АОТ). Она ориентирована на то, что можно изначально заполнить спецтабличку (xrefTypeHierarchy) из формы построения перекрестных ссылок, а затем уже выбирать оттуда информацию гораздо быстрее, чем с помощью п.1

Я иногда задумываюсь - а не станет ли облегчение программирования в будущем усложнением в другом месте? Т.е. вроде как все знают - добавил наследника - он не активируется, пока его не пропишешь в конструкторе. А тут он взял и сам прицепился. Нетипичное поведение по сравнению с другим кодом. Что усложняет процесс изучения кода.

ЗЫ. Пока писал - уже AndyD ответил. Его вариант - наверное даже лучше, чем мой п.1

[belugin]

Цитата:

Сообщение от AndyD

У найденных классов, соответственно, так же дергать extendedBy()

На Ax2012, по крайней мере, параметр allLevels по умолчанию true - то есть у найденных уже не надо дергать.

Цитата:

Вот только, овчинка выделки не стоит, имха

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

Только чтоб это быстро работало применяется агрессивное кеширование.

Цитата:

Сообщение от belugin

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

Только чтоб это быстро работало применяется агрессивное кеширование.

Агрессивное это как?
Я еще в AX2009 работаю, не могу посмотреть пример.

У меня случай простейший, нужный класс определяется TableId переданной записи.
Первое, что пришло в голову для кэширования, сделать постоянную таблицу с соответствием TableId и ClassId.
Если класс не найден в ней, то автоматом заполнить таблицу с помощью перебора extendedBy(), если не помогло, то выкинуть ошибку.

Если вдруг у другого базового будет такая же тема с TableId - ClassId, добавим еще поле BaseClassId и поиск в конструкторе будем осуществлять в его разрезе.

[belugin]

Агрессивное, значит кешируют все, до чего могут дотянуться.

Там соответствие классов параметрам делается с помощью атрибутов, которых нет в X++ в Ax 2009.

Но в принципе можно сделать и статический метод.

[dech]

Создание класса будет работать дико медленно. Ребят, вам что жалко construct() допилить? Вам что важнее, скорость или эстетство?

[S.Kuskov]

Цитата:

Сообщение от Кирилл

Если класс не найден в ней, то автоматом заполнить таблицу с помощью перебора extendedBy(), если не помогло, то выкинуть ошибку.

Не не. Лучше сразу выкидывать ошибку. А для поиска новых классов сделать отдельную переодическую операцию. В противном случае процесс создания экземпляра класса становится не детерминированным. Сегодня всё работает быстро, а завтра начинаются тормоза или вообще ошибки вырастают на ровном месте. Для не искушённого пользователя такие перепады "настроения" системы сложно как-то оправдать. Чем прозрачнее процесс, тем проще его контролировать.

Цитата:

Сообщение от dech

Создание класса будет работать дико медленно. Ребят, вам что жалко construct() допилить? Вам что важнее, скорость или эстетство?

Угу.

Отказ от протягивания динамических связей в пользу статического метода construct приводит к ещё более прозрачному процессу. В конце концов появление новых классов потомков у вас же не поставленно на поток и не происходит автоматически?

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