AX2012. Цель атрибутов в расширении наследования классов

[belugin]

Цитата:

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

именно!
ключевое слово "сделать".
если нужно "сделать", то зачем нужен какой-то левый ключ?
давайте будем "сделать" сразу имя класса? и атрибутов писать не нужно.

Проанализируй ключ в твоем примере - он составной - модуль и Node - можно их заменить именами классов?

Цитата:

Снова приношу свои извинения за безумную реализацию от МС.
Нет, у меня не нужен класс запускач. Достаточно menuItem, который подцепляется к главному меню или к формам.

У тебя есть класс с методом main, который все это знает. Я думал ты его имеешь ввиду. Я не создавал новых классов кроме атрибута. Есть класс-создаватель (фабрика) он готовый и я его не менял.

Цитата:

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

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

Цитата:

В фреймворке один стратегия должна знать обо всех классах иерархии.

Не понял.

Цитата:

ты снова прав для случая без параметров.
но как часто используется именно этот сценарий?

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

1. Во базовый класс добавляется метод init с нжными параметрами
2. Сразу после создания он вызывается.

Цитата:

выбери любой из них, который реализует несколько уровней иерархии.

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

Цитата:

Покажи как это просто.

Ты говоришь "просто добавить атрибуты".
Ты говоришь "просто смотреть"
Сделай проектик. Покажи как это просто.

Ok чуть попозже. Только учти что у тебя добавление элемента к существующему механизму создания объектов. А у меня будет еще и немного кода на перевод на новый механизм (как если бы ты перевел все на if вместо case )

Цитата:

И в самом деле! Чего это я? Видать Котлинов всяких наелся...

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

Цитата:

Я смотрю актуальную аксапту. 7.2.1785.0
Да-да. Я вижу это "что угодно". Строка с ; Это пипец и детский сад какой-то.

Это я не понял.

Цитата:

Кем и как? Бгггг!!

Так же как и сейчас - кто и как распределяет префиксы в именах классов, чтобы партнерские классы не конфликтовали с микрософтовскими при обновлении.

Цитата:

вспомнить, исходный вопрос ветки был: "Какая цель создания экземпляров классов через расширенные атрибуты? Чем не устраивает старый дедовский способ construct?"

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

Цитата:

Ребяты, прошу вас, не надо примеров "я создал пример из трех классов, я добавил атрибуты". такие примеры ничего не показывают.

Зачем ты его просишь тогда?

Цитата:

Давайте рассматривать нормальный промышленный случай:
= которые добавляют/изменяют функционал этого семейства (одновременно или последовательно). в пределе это программисты разных партнеров, которые делают разные типовые решения. а некий программист заказчика ставит эти пересекающиеся типовые решения [из разных моделей]. (в целях упрощения, для данной ветки можно предположить, что модель одна, чтобы рассмотреть только механизм инстанцирования класса)
= как облегчить работу этих людей?

(Заметь что ты используешь разметку типа маркдауна внутри сообщения, но свою )

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

Цитата:

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

Я видел два способа. 1) GUID 2) Сесть на какой-то уже готовый способ распределения имен, например в java привязываются к домену комании (com.microsoft.dynsmics.forOperations) который распределяется в интернете.

Я предпочитаю привязываться к именам классов и таблиц.

Цитата:

Как должны выглядеть эти ключи, чтобы в принципе была возможность рефакторинга? (да, я знаю что МС не рефакторит, но у партнеров и у заказчика то могут работать нормальные люди)

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

Цитата:

Зачем вообще нужны специальные ключи вместо имен классов?

Чтобы создавать классы на основе бейзэнамов, например. В принципе, можно было бы обойтись одними классами, но MorphX не поддерживает автоматизацию создания UI для классов. Именно поэтому твой case не по классам а по base enum и строчке - в menuItem нельзя записать три параметра все из которых были бы классами.

Еще можно использовать сами классы в качестве ключей - посмотри SysClassNameAttribute