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)

Цитата:

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

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

[EVGL]

А можно поинтересоваться, как вы создаете окружность по двум точкам? : )

[belugin]

Цитата:

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

А можно поинтересоваться, как вы создаете окружность по двум точкам? : )

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

[mazzy]

Цитата:

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

А можно поинтересоваться, как вы создаете окружность по двум точкам? : )

или окружность бесконечного радиуса, проходящая через заданные точки.

[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.

[ax_mct]

Brian decides a magic climbing fork is the best way to climb into the tower to retrieve the amulet and get home.
https://www.youtube.com/watch?v=44IgPvJJpa0

[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.

[belugin]

Цитата:

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

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

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

.

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

[ax_mct]

Цитата:

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

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

Наши знания и компетентность - отдельно, Аксапта и уместность для нее паттернов - отдельно.

Мой пойнт в том что любые паттерны проектирования - overengineering. В том числе данный патентованный способ использования атрибутов. Оverengineering до тех пор пока не доказано и показано обратное. Как с той вилкой для подьема по стене.

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

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

[ta_and]

Цитата:

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

только те параметры которые принимает main

Эти слова да МС бы в уши... Но это другой уровень организации вызова объектов. Слишком кардинально нужно менять всю систему. Это уже не один параметр, это меняет не только один системный вызов обжекта, но требует изменения всей среды разработки и передачи событий между объектами... В общем, это на порядок более нереальная придумка, чем моя с аргс. )) Хотя, я полностью ЗА!

[fed]

Я бы переформулировал проблему, затронутую ax_mct следующим образом: Мы занимаемся автоматизацией бизнес процессов. Заметная часть участников этих самых бизнес процессов - люди весьма среднего образования и интеллекта. Поэтому все слишком сложно спроектированные бизнес-процессы, с течением времени либо упрощаются либо умирают.
Поэтому для меня использование в X++ коде слишком большого числа паттернов говорит о том что бизнес-проблема изначально неправильно сформулирована. Если бизнес-процесс описан правильно, то и код не будет выглядеть как набор примеров из Gang Of Four. Классический пример - это архитектура Source Document/Distribution/Subledger. Изначально безумный набор бизнес-требований привел к еще более безумной архитектуре. Вероятно с точки зрения разработчиков, которые этот код писали - никакого overengineering не было. Это еще просто чудо что тот код, который эту фигню реализует, все еще можно понять и как-то описать. Но вот с точки зрения соответствия этого модуля прикладной реальности на внедрениях - имеется overengineering и еще и какой.
Мы ведь в конце концов не биржевой скальпер пишем, не программу игры в Го и не предсказатель погоды. Если у вас разработка без десятка паттернов не получается, попробуйте с постановщиком поговорить.Скорее всего, он просто какой-то бред в спецификации написал, или вы просто половины требований не поняли...

[EVGL]

Цитата:

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

Классический пример - это архитектура Source Document/Distribution/Subledger. Изначально безумный набор бизнес-требований привел к еще более безумной архитектуре. Вероятно с точки зрения разработчиков, которые этот код писали - никакого overengineering не было. Это еще просто чудо что тот код, который эту фигню реализует, все еще можно понять и как-то описать. Но вот с точки зрения соответствия этого модуля прикладной реальности на внедрениях - имеется overengineering и еще и какой.

Отнюдь. Ничего безумного в требованиях нет. Предварительный просмотр проводок с журналов ГК был сделан по-простому Ушаковым еще 15 лет назад. Прикладной реальности реализация соответствует идеально, жаль лишь что эта реализация покрывает лишь где-то 30% мест, где есть документы и проводки.

[fed]

Цитата:

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

Отнюдь. Ничего безумного в требованиях нет. Предварительный просмотр проводок с журналов ГК был сделан по-простому Ушаковым еще 15 лет назад. Прикладной реальности реализация соответствует идеально, жаль лишь что эта реализация покрывает лишь где-то 30% мест, где есть документы и проводки.

Гм. Про предварительный просмотр я помню конечно. Проблема в том, что вместо предварительного просмотра сделали монстра, который позволяет отвязать проводки от экономического смысла операции. Кроме того - они там почему-то решили оторвать разноску в ГК от разноски по модулю, ввести понятие исходного документа (который вообще-то не само экономическое событие, а просто некий полуслучайный носитель информации об экономическом событии) и тд и тп.
Собственно из за бредовости привязки экономического события к документу и случилось что "только 30% мест" были покрыты.
Кроме того - возможность посмотреть планируемые проводки до разноски - это такая удобная фича. Она полезна конечно, но вряд ли настолько полезна чтобы сломать механизм разноски и отвязать разноску в ГК от разноски по модулю...
В итоге - я бы сказал что 85% багов в финансовом модуле DAX2012 случались как раз из за того что этот монстр как-то не очень хорошо интегрировался с остальными местами системы...