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

[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%!!! исключает зоопарк в передаваемых структурах данных при инициализации.
Энитайп же ни о чем не говорит. Совершенно. Он не типизирован. Поэтому использование его в контракте не является правильным решением.
Проверка переданных данных лежит полюбому на создаваемом классе.
---------
Вы же не будете утверждать, что использование контракта избавляет от необходимости проверки входных данных?

[belugin]

Цитата:

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

Нет. не все равно.
На моем опыте 90% классов на вход принимают енум и курсор.
Эти 90% классов вполне покрываются передачей на вход аргс.
Энитайп же ни о чем не говорит. Совершенно. Он не типизирован.

Так args содержит any type. И 90% классов (кстати интересно вообще всех классов или классов, которые вы добавляете/изменяете) принимают не запись вообще а запись какого-то определенного типа. И энам тоже не любой. И указывание не нужных параметров создает кашу в голове а не приводит мозги в порядок.

Цитата:

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

Почитайте про design by contact - это не то же самое что data contracts .

Да проверять нужно по-любому. По крайней мере пока нет зависимых типов. Но я бы сделал наоборот - не передавал бы везде запись и enum - нужны они там или не нужны а в menu item поздравлял бы указывать только те параметры которые принимает main: нужна запись - попросить запись причем нужного типа, нужен enum - попросить enum, нужно два - просить два.

Вы же сами не хотите any type - потому что нужна проверка при компиляции. Но почему-то хотите any record и anyenum.

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

[ax_mct]

Цитата:

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

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

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

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

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

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

[belugin]

Цитата:

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

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

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

.

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