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

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

[ta_and]

Цитата:

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

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

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

[ax_mct]

Цитата:

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

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

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

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

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

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

[belugin]

Цитата:

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

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

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

.

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

[ax_mct]

Цитата:

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

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

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

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

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

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

[skuull]

Цитата:

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

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

Атрибуты решают вполне конкретную задачу - добавление нового класса в иерархию без изменения родительского класса, что особенно актульно в 7ке, т.к. не надо оверлеить.
Паттерны из GoF и подобная литература решает конкретную задачу в программировании и очень жалко что по историческим причинам в АХ попадают люди предпочитающие методы по 2000 строк потому что "все в 1 месте, так удобней" и отрицающие все что "не как в 4ке". Выглядит как-то так

[ax_mct]

Цитата:

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

Атрибуты решают вполне конкретную задачу - добавление нового класса в иерархию без изменения родительского класса, что особенно актульно в 7ке, т.к. не надо оверлеить.
Паттерны из GoF и подобная литература решает конкретную задачу в программировании и очень жалко что по историческим причинам в АХ попадают люди предпочитающие методы по 2000 строк потому что "все в 1 месте, так удобней" и отрицающие все что "не как в 4ке". Выглядит как-то так

Мама там на картинке - права. На велосипеде с каменными колесами далеко не уедешь.

Эти аттрибуты даже не паттерн - это костыль. Причем кривой. Да, решает задачу.
Искусственной проблемы.

Есть фундаментальные правила конкретной системы основанные на изменении слоев.
Best Practices for Static Construct Methods
https://msdn.microsoft.com/en-gb/library/aa637432.aspx

Даже если отставить в сторону вопрос идиотизма блокирования и принять extension model как данность то не такие костыли нужны системе, а многое другое, в частности переопределение и замена статических методов включая ::construct.

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

[dech]

Цитата:

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

Атрибуты решают вполне конкретную задачу - добавление нового класса в иерархию без изменения родительского класса, что особенно актульно в 7ке, т.к. не надо оверлеить.
Паттерны из GoF и подобная литература решает конкретную задачу в программировании и очень жалко что по историческим причинам в АХ попадают люди предпочитающие методы по 2000 строк потому что "все в 1 месте, так удобней" и отрицающие все что "не как в 4ке". Выглядит как-то так

А кто сказал, что в 4-ке нельзя сделать иерархию без изменения родительского класса?
Создаём базовый класс:

public class PPO_Base
{
}

protected void new()
{
}

public str getType()
{
    return "Base";
}

public static PPO_Base construct(IdentifierName _className = classstr(PPO_Base))
{
    DictClass       dictClass   = new DictClass(classname2id(_className));
    ;

    if (!dictClass)
        throw error(strfmt("Unable to instantiate \"%1\" class", _className));

    return dictClass.makeObject();
}

public static void main(Args _args)
{
    IdentifierName  className   = _args ? _args.parm() : classstr(PPO_Base);
    PPO_Base        instance    = PPO_Base::construct(className);
    ;

    info(strfmt("Class type: %1", instance.getType()));
}

А потом делаем сколько угодно наследников:

public class PPO_Derived extends PPO_Base
{
}

public str getType()
{
    return "Derived";
}

Создаем менюайтемы для каждого класса. В строковом параметре пишем имя класса. (Для базового класса параметр может быть пустым). Если сильно надо, можно создать енум для иерархии, но необходимости нет, имхо.
Как использовать в коде:

PPO_Base    base    = PPO_Base::construct();
PPO_Base    derived = PPO_Base::construct(classstr(PPO_Derived));
;

info(strfmt("Base class type: %1", base.getType()));
info(strfmt("Derived class type: %1", derived.getType()));