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

[ta_and]

Цитата:

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

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

Ок, Гугл!! ))
Я все время испытывал ужасный дискомфорт, когда нарушал это правило ВР.
И мне было неудобно перед теми программистами, кто знает ВР и может меня упрекнуть в нарушении этого правила.
И тут... тадам.
SysOperationServiceController
метод
new
!!!
Улыбаемся и машем!
Если кто-то скажет, что это неправильный класс и так нельзя делать, то даже не знаю что и подумать....
-----------------
На самом деле, я бы для ВСЕХ классов, по умолчанию!, сделал в методе нью необязательный? параметр с типом Args.
В большинстве случаев как раз при инициализации класса НЕОБХОДИМЫ! параметры для исключения ошибок дальнейшей инициализации и работы класса.
Я не могу себе даже представить такую ситуацию, в которой необходим чистый класс, который на входе не принимает никаких параметров вообще.
Возможно, я ошибаюсь. Можете привести хоть один пример класса, в котором не нужны параметры?...
---------
Может быть выделить это обсуждение в отдельную тему? А то офтопик получается...

[belugin]

Цитата:

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

На самом деле, я бы для ВСЕХ классов, по умолчанию!, сделал в методе нью необязательный? параметр с типом Args.

Почему не AnyType

Цитата:

В большинстве случаев как раз при инициализации класса НЕОБХОДИМЫ! параметры для исключения ошибок дальнейшей инициализации и работы класса.

Вероятно имеется ввиду, что надо делать protected new и инициализировать параметрами фабричными методами. Чтобы было

Circle::createByCenterAndRadius(p1, r1);
Circle::createByTwoPonts(p1, p2)

А не new Circle(null, 0, p1, p2)

Цитата:

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

Какой-нибудь билдер, которому проще надиктовать параметры последовательно.

[ta_and]

Цитата:

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

Почему не AnyType

Потому что анитайп слишком расплывчато. Он не типизирован и не прозрачен. Неизвестно чего он него ждать.
Аргс используется как буфер обмена повсеместно, во всей системе, формы, main, джобы...Это де-факто - параметр по умолчанию. Почему бы его не использовать и для инициализации классов?

[belugin]

Цитата:

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

Потому что анитайп слишком расплывчато. Он не типизирован и не прозрачен. Неизвестно чего он него ждать.

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

Аргс используется не повсеместно а только в коде который вызывается непосредственно из UI. Он содержит UI специфичные параметры, а остальное фактически так же нетипизировано как AnyType

[mazzy]

Цитата:

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

Аргс используется не повсеместно а только в коде который вызывается непосредственно из UI.

да. права, метка и подсказка на разных языках, параметр где запускать... и прочие "специфичные" UI параметры.
и не говори, очень жаль, что "используется не повсеместно".

[ta_and]

Цитата:

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

только там может быть незаполнено

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

[belugin]

Цитата:

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

Повсеместно используемое место.

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

Почитайте про design by contract и вообще про принципы проектирования

[ta_and]

Цитата:

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

Это все равно, что AnyType

Нет. не все равно.
На моем опыте 90% классов на вход принимают енум и курсор.
Эти 90% классов вполне покрываются передачей на вход аргс.
Можно считать, что это типизированная передача фиксированных параметров в контракте. Возможно, для некоторых классов избыточная. Но зато (если бы это было так) унифицированная для всех объектов системы! А это приводит в порядок мысли в голове разработчиков новой функциональности, и конкретным ожиданиям для существующей. И на 90%!!! исключает зоопарк в передаваемых структурах данных при инициализации.
Энитайп же ни о чем не говорит. Совершенно. Он не типизирован. Поэтому использование его в контракте не является правильным решением.
Проверка переданных данных лежит полюбому на создаваемом классе.
---------
Вы же не будете утверждать, что использование контракта избавляет от необходимости проверки входных данных?

[ax_mct]

Цитата:

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

Почитайте про design by contract и вообще про принципы проектирования

Вот лучше бы те кто такое читают в Аксапту бы не лезли. Ей от этого дурно, а сейчас вообще подыхает

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

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

Я например не вижу как это что-то упрощает или экономит в контексте даже AX7. Не нужно загодя решать потенциальные проблемы. Это overengineering.