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

[ta_and]

Здравствуйте.
У меня возникли чисто теоретические вопросы.
1. Какая цель создания экземпляров классов через расширенные атрибуты
SysExtensionAppClassFactory::getClassFromSysAttribute(
?
2. Чем не устраивает старый дедовский способ construct ?
3. Как при создании экземпляра класса через расширенные атрибуты передать ему параметры в new?

ПС. Я исхожу из принципа, что вызывающий класс и так ВСЕГДА должен знать какого наследника он создает. Зачем тогда городить огород и не вызывать просто создание нужного наследника? Типа свич лишний, давайте загрузим ядро, у него голова большая, пусть думает? Или у нас наследники классов растут как грибы, не успеваем исправлять конструктор, нужно через атрибуты это делать?...

[ax_mct]

Как вариант такое обьяснение. Для как бы mapping через metadata, то есть для связки но не трогая код.
Но я конечно не уверен, это так - для темы.

Цитата:

есть у вас класс Point с полями X и Y
class Point
{
public int X {get; set;}
public int Y {get; set;}
}
Вы хотите его сериализовать в JSON. Окей, не вопрос, даже ничего не понадобится. Однако теперь есть проблема, точки нужно отдать в стороннюю библиотеку, где они должны назваться PTXCOORD и PTYCOORD. Естественно, свой код вы захламлять не хотите, у точки есть координаты X и Y, не нужно все эти дебильные прфиксы и суффиксы писать (однако эта библиотека принимает данные только в таком формате. И вот, здравствуйте, атрибуты:

[DataContract]
class Point
{
[DataMember(Name = "PTXCOORD ")]
public int X {get; set;}
[DataMember(Name = "PTYCOORD ")]
public int Y {get; set;}
}
Всё. Ваш код будет работать с нормальными именами, библиотека получит данные в нужном формате, все довольны.

Про WCF я и не говорю, там чуть менее чем всё на атрибуты завязано.

Что такое атрибуты и зачем они? Для чего нужны директивы препроцессора? - C#
http://www.cyberforum.ru/csharp-begi...ad1776997.html

[Raven Melancholic]

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

Цитата:

старый дедовский способ construct

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

Цитата:

передать ему параметры в new

new с параметрами в описании BP не рекомендуется уже с DAX4, то есть более 10 лет. Кстати и construct с параметрами не рекомендуется к применению с тех же пор.

Цитата:

вызывающий класс и так ВСЕГДА должен знать какого наследника он создает

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

[ta_and]

Цитата:

Сообщение от Raven Melancholic

при создании наследников не менять существующий код

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

Цитата:

Сообщение от Raven Melancholic

уже существующего отлаженного кода

Правильное добавление наследника никак не может повлиять на существующий код.

Цитата:

Сообщение от Raven Melancholic

new с параметрами в описании BP не рекомендуется уже с DAX4, то есть более 10 лет. Кстати и construct с параметрами не рекомендуется к применению с тех же пор.

Где в теории ООП написано, что конструктор должен быть без параметров?!
Совершенно не оправданное ограничение МС.
Приведите хотя бы один довод, почему в конструктор не должны передаваться параметры?

Цитата:

Сообщение от Raven Melancholic

..код, использующий какие-то классы из иерархии не должен делать предположение..

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

[belugin]

Цитата:

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

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

Нет, не надо будет - надо будет добавить новое значение атрибута и не туда где он вызывается. А, навпример, в BaseEnum.

Цитата:

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

Чтобы при мердже кода не мержить свитч.

[trud]

Цитата:

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

Вопрос - зачем атрибут, если можно через свич легко и просто?

Мне думается вот хорошее видео которое объясняет в целом концепцию
Антон Кекс — Как нам спасти Java
https://www.youtube.com/watch?v=TSAlj04_tkA
Вкратце - представьте что вас взяли архитектором в Микрософт. если вы предложите писать все через switch, то собственно возникнет вопрос нафиг вы тогда вообще нужны, switch и так все знают. Поэтому собственно идет расширение концепций(при чем принцип чем запутаннее, тем лучше).
Вот кстати товарищ Мартин предлагает вообще использовать библиотеку Автофак для подобных вещей
goshoom: IoC containers for extensibility
если он сумеет продвинуть это, то в следующей версии будем разбираться уже с этим
Кстати один из примеров который приводит Антон - это то что на каком то проекте куда они пришли довнедрять было вообще запрещено писать бизнес логику на Джава, все должно быть на SQL. когда начали разбираться откуда пошло это безумное требование, оказалось что если разрешить писать на Джава вещи типа сделать проводку, то получаются конструкции "когда класс создает другой класс чтобы через интерфейс вызвать третий" и т.п. и через некоторое время понять что происходит становится невозможно. SQL этого не позволяется, там собственно всегда можно увидеть что происходит с данными
это кстати вспоминается когда приходится отлаживать что-то из Source Framework в Ах.

[mazzy]

Цитата:

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

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

Угу.

Цитата:

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

Чтобы при мердже кода не мержить свитч.

Ключевой вопрос: а почему "не мержить свитч" лучше?

Ведь use case все равно проверять, все равно придется копать все ветки кода, поскольку все равно останется угроза рефакторинга остальных веток кода. Все равно придется расширять test cases, все равно придется дописывать документацию, все равно придется обеспечивать совместимость.

Атрибут и свитч - это настолько небольшая часть работы в общем проекте. Но технология атрибутов получилась настолько отличной от остальной работы.

Так вот: а почему "не мержить свитч" лучше?

Цитата:

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

Антон Кекс ... то собственно возникнет вопрос нафиг вы тогда вообще нужны, switch и так все знают.

Кекс экстремист своего рода )
Хоть и очень толковый. Но он судит людей по себе.

На самом деле все проще.
Как и остальные люди, специалисты в МС хотят сделать лучше, проще, быстрее. Просто "критерии лучшести" в МС сильно отличаются от остальных людей.

Можно много говорить на тему "почему отличаются". Это отдельная тема.

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

[S.Kuskov]

mfp: SysExtension Framework – to the rescue

[mazzy]

а также доп.вопросы к SysExtension framework:
Kashperuk Ivan: Development tutorial: SysExtension framework in factory methods where the constructor requires one or more arguments

[belugin]

Цитата:

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

Угу.
Ключевой вопрос: а почему "не мержить свитч" лучше?

Ведь use case все равно проверять, все равно придется копать все ветки кода, поскольку все равно останется угроза рефакторинга остальных веток кода. Все равно придется расширять test cases,
все равно придется дописывать документацию, все равно придется обеспечивать совместимость.

См. дальше дискуссия extensions vs overlayering. Скажу только, что можно скономить на легко автоматизируемых вещах время для трудноавтоматизируемых вещей.

[mazzy]

Цитата:

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

См. дальше дискуссия extensions vs overlayering.

)

Цитата:

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

Скажу только, что можно скономить на легко автоматизируемых вещах время для трудноавтоматизируемых вещей.

справедливости ради стоит отметить, что:

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

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

[ta_and]

Цитата:

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

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

ВОТ! Точно и ясно высказанная цель, которую я не мог сформулировать.
Других целей я не вижу.

[dech]

Цитата:

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

ВОТ! Точно и ясно высказанная цель, которую я не мог сформулировать.
Других целей я не вижу.

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

[mazzy]

Цитата:

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

Цель МС давно известна - сделать разделение кода

Цель МС давно известна - заработать.

"Сделать разделение кода" не является (и не может являться) целью корпорации МС )))

[mazzy]

Давайте отвечу публично:
Нет, это не придирки к русскому языку и правописанию.

Допустим, что в утверждении подразумевался не МС, а некие мифические "разработчики МС".
Тогда получается утверждение "Цель разработчиков МС давно известна - сделать разделение кода".
Но при этом утверждение, что "цель корпорации МС - заработать" остается верным.

Отсюда тривиальный вопрос - а как выполнение цели этих мифических разработчиков МС позволит выполнить цель корпорации МС? каков механизм?

На самом деле вопросов встает очень много.
Это если нормально сформулировать мысль, не делая никаких неоправданных логических допущений.

[sukhanchik]

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

[mazzy]

Логично, чё!

Цитата:

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

Уменьшение трудозатрат МСа при выпуске новых версий даст возможность уменьшить расходы.

Предположим )))

Прямой вопрос к твоему тексту:
А как "уменьшение трудозатрат МСа" повлияет на число купленных лицензий (доход)? Увеличит? Сохранит на прежнем уровне? Уменьшит? Почему?

Косвенный вопрос:
dech сказал "сделать разделение кода"
ты говоришь "Уменьшение трудозатрат ..., технология ... позволяет ему снизить свои издержки"
а "разделение кода" точно позволит МСу "снизить свои издержки"? каков механизм?

))))

В общем, ребяты, давайте тщательнее. Пожалуйста.

[Владимир Максимов]

Цитата:

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

Где в теории ООП написано, что конструктор должен быть без параметров?!

В теории, разумеется, этого нет. Но Axapta - это не "теория". Это "экземпляр" теории Конкретная реализация, которая, разумеется, вводит свои собственные ограничения

Цитата:

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

Совершенно не оправданное ограничение МС.
Приведите хотя бы один довод, почему в конструктор не должны передаваться параметры?

Оправдано, оправдано. Но! Не "вообще", а в конкретной реализации ООП в системе Axapta. Самый простой пример - пакетные задания (Batch) начинаются с того, что создают экземпляр класса через

classfactory.createClass(classId);

передача параметров здесь не предусмотрена "в принципе". Все "параметры" поднимаются из unpack уже "потом". После инициализации

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

Собственно, сделайте поиск по перекрестным ссылкам, где используется хотя бы classfactory.createClass() не говоря уже о DictClass.makeObject(). Удивитесь как много подобных вызовов

Поэтому, чтобы не получить проблему "на ровном месте" в среде Axapta следует жестко придерживаться правила

Никаких параметров в методах new

Да, в большинстве случаев, у Вас проблем не будет, если Вы передадите параметр в new. Но однажды, в самый неподходящий момент, все "вдруг" перестанет работать

[mazzy]

Цитата:

Сообщение от Владимир Максимов

Собственно, сделайте поиск по перекрестным ссылкам, где используется хотя бы classfactory.createClass() не говоря уже о DictClass.makeObject(). Удивитесь как много подобных вызовов

Поэтому, чтобы не получить проблему "на ровном месте" в среде Axapta следует жестко придерживаться правила

Никаких параметров в методах new

Да, в большинстве случаев, у Вас проблем не будет, если Вы передадите параметр в new. Но однажды, в самый неподходящий момент, все "вдруг" перестанет работать

Ураа!!! ответ по существу!!!!

а давайте вернемся к исходному вопросу?

Цитата:

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

Здравствуйте.
У меня возникли чисто теоретические вопросы.
1. Какая цель создания экземпляров классов через расширенные атрибуты
SysExtensionAppClassFactory::getClassFromSysAttribute(
?
2. Чем не устраивает старый дедовский способ construct ?
3. Как при создании экземпляра класса через расширенные атрибуты передать ему параметры в new?

ПС. Я исхожу из принципа, что вызывающий класс и так ВСЕГДА должен знать какого наследника он создает. Зачем тогда городить огород и не вызывать просто создание нужного наследника? Типа свич лишний, давайте загрузим ядро, у него голова большая, пусть думает? Или у нас наследники классов растут как грибы, не успеваем исправлять конструктор, нужно через атрибуты это делать?...

Как утверждение "Никаких параметров в методах new"
довести до ответов на исходные вопросы?

[mazzy]

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

да, classfactory.createClass() и DictClass.makeObject() используется дофига где.
существуют ли на ваш взгляд более оптимальные (для всех причастных к аксапте) решения нежели "Никаких параметров в методах new"?