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

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

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

[skuull]

Цитата:

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

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

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

Есть какие-то "общепринятые" вещи в программировании, про Барбару Стрейзанд Лисков тут уже вспоминали, есть еще Принцип открытости/закрытости. Тоже наверно искусственный принцип. Некоторые даже скажут, что знание этих принципов категорически мешает на внедрениях, ведь удорожает поддержку кода и его усложняет.

[ax_mct]

Цитата:

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

Есть какие-то "общепринятые" вещи в программировании, про Барбару Стрейзанд Лисков тут уже вспоминали, есть еще Принцип открытости/закрытости. Тоже наверно искусственный принцип. Некоторые даже скажут, что знание этих принципов категорически мешает на внедрениях, ведь удорожает поддержку кода и его усложняет.

Нет "общепринятых" вещей в программировании. Есть те которые приняты в конкретном фрэйморке, продукте, платформе. То есть уместны.

Я до сих пор помню глаза напарника индуса когда завернул Java в X++. И помню свои крепкие матюги на "общепринятые" вещи от блистательного программиста C#.

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

Применительно к Аксапте, запрету overlayering и костылям в виде этих аттрибутов - если это следование "общепринятым" вещам в программировании то кто-то проклял всех программистов, а программистов AX в особенности.

Я вижу Extension model для AX как просто запрет на программирование. Если же это таки альтернатива то она существенно дороже и намного опаснее чем overlayering.
Создание наследников через атрибуты чтобы следовать Extension model - это способ лечения зуба когда рот зашит.

Цитата:

При́нцип откры́тости/закры́тости (англ. The Open Closed Principle, OCP) — принцип ООП, устанавливающий следующее положение: «программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения»

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

[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()));

[skuull]

Цитата:

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

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

А кто сказал что нельзя? Я сказал что не принято. Оно ж примерно на атрибутах так и работает, просто ненадо свой конструктор каждый раз писать.
А в этой реализации было бы неплохо проверить, что _className являеться наследником базовго класса и getType() у вас вышел какой-то бесполезный, только инфо показывать

[dech]

Цитата:

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

А кто сказал что нельзя? Я сказал что не принято. Оно ж примерно на атрибутах так и работает, просто ненадо свой конструктор каждый раз писать.
А в этой реализации было бы неплохо проверить, что _className являеться наследником базовго класса и getType() у вас вышел какой-то бесполезный, только инфо показывать

1. Вместо Construct() можно запилить всего одну глобальную функцию
2. Это учебный пример, лишнего не писал для ясности
3. Любой каприз за ваши деньги

[ta_and]

Цитата:

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

1. Вместо Construct() можно запилить всего одну глобальную функцию

Да да! и на вход Аргс! )))

[dech]

Цитата:

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

Да да! и на вход Аргс! )))

А зачем вам Args, если требуется только создать нужный инстанс?

[ta_and]

Цитата:

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

А зачем вам Args..?

Каждому инстансу - по параметру! )
Мы же не рассматриваем сферического коня в вакууме, которому совсем параметры не нужны?..