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

[mazzy]

Цитата:

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

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

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

Цитата:

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

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

в проекте на конструкторах не было main, который ВСЕ ЗНАЕТ. было main, которые знали о себе (как обычно)
в проекте на конструкторах не было contruct, который ВСЕ ЗНАЕТ. было два конструктора. каждый знает только о своем уровне и принимает решение своего уровня.

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

Цитата:

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

Тогда выбери любой другой пример.

не, давай пока останемся на том же самом - расширить функционал автосопоставления.
по идее, в этом примере не хватает параметров. ну и фиг с ними.

Цитата:

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

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

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

Давай лучше поговорим о трудоемкости и об ответстенности за правильность результата.
Как бы ты оценил трудоемкость и удобность по сравнению со старым методом?
Мое мнение: Через жопу по сравнению со старым конструкторским методом.

Цитата:

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

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

Вооот!!!
И мы подошли к трудоемкости и удобствам.

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

Цитата:

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

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

Именно!
Я посмотрел в существующий функционал насколько хватило терпения.
Пипец!!!

Цитата:

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

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

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

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

Но фиг с ним. Давай пока останемся в рамках задачи "добавление класса в иерархию"

Цитата:

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

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

Да, ортогональный
Да, никакой асинхронности.
Да, я совершенно зря загорелся надеждой...

Цитата:

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

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

"Также как и сейчас" - это ты очень хорошо сказал.
Если "также как и сейчас", то нафига огород городить?
А да, вспомнил, МС закрывает код базовых классов...

Цитата:

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

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

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

Цитата:

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

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

и в самом деле!

Цитата:

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

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

Заметь, что в эту разметку никто не будет встраивать свои сообщения. На форуме при цитировании делается копия, старый текст и добавляется текст. И здесь нет компиляции )))

Цитата:

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

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

Макс... Я понимаю что ты хочешь сказать. Но просто сделай проектик (чуть более сложный чем одноувроенвое семейство из трех классов) И покажи в нем что хочешь сказать.

Цитата:

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

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

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

Цитата:

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

Чтобы создавать классы на основе бейзэнамов, например.

я понимаю, что ты хочешь сказать. но так делают только внутри МС.

Цитата:

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

Именно поэтому твой case не по классам а по base enum и строчке - в menuItem нельзя записать три параметра все из которых были бы классами.

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

Цитата:

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

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

Да-да. У меня это был второй или третий вариант. В этом случае связь с классами автоматом, но зато связь с menuItem нужно делать руками.

Я старался сделать минимальный код при помощи штатных средств.

[belugin]

Цитата:

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

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

Заметь, что в исходном проекте использующем case делается специальное текстовое значение, которое повторяется в нескольких местах.

Цитата:

в проекте на конструкторах не было main, который ВСЕ ЗНАЕТ. было main, которые знали о себе (как обычно)
в проекте на конструкторах не было contruct, который ВСЕ ЗНАЕТ. было два конструктора. каждый знает только о своем уровне и принимает решение своего уровня.

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

Цитата:

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

В чем проблема с валидацией? Если ее надо делать до определения потомка, то вставить в вызывающий класс, если после, то в базовый.

Цитата:

Давай лучше поговорим о трудоемкости и об ответстенности за правильность результата.
Как бы ты оценил трудоемкость и удобность по сравнению со старым методом?
Мое мнение: Через жопу по сравнению со старым конструкторским методом.

Трудоемкость какого сценария? Добавление нового элемента - чуть меньше. Создание самой точки расширения - чуть больше или такая же.
Апгрейда при условии отсутствия breaking changes меньше.
Поиска зависимостей - примерно такая же.

Цитата:

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

Тут никакой иерархии атрибутов нет, атрибут ровно один.

Цитата:

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

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

Цитата:

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

В новом - меньше.

Цитата:

Да, ортогональный
Да, никакой асинхронности.
Да, я совершенно зря загорелся надеждой...

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

Цитата:

"Также как и сейчас" - это ты очень хорошо сказал.
Если "также как и сейчас", то нафига огород городить?

Чтобы в других аспектах было не так же как и сейчас. Не все сразу.

Цитата:

Макс... Я понимаю что ты хочешь сказать. Но просто сделай проектик (чуть более сложный чем одноувроенвое семейство из трех классов) И покажи в нем что хочешь сказать.

Сконвертировал пример c case на жкстеншены. Не тестировал - мне кажется ты разобрался в концепции.