D365FO: Inheritance + Extensions + RealTime

[malex]

Есть 8.0 PU15. Переношу overlaid-решение на extensions.

В классе InventMovement был кастом-метод, который был перекрыт в наследниках (InventMov_Purch)
Я создал extensions к этим методам и ожидаю, что в real-time вызовется нужный extension:

[ExtensionOf(classStr(InventMovement))]
final class InventMovementAQM_Extension
{
    boolean AQMmustUpdateBatchInfo()
    {
        return false;
    }
}

[ExtensionOf(classStr(InventMov_Purch))]
final class InventMov_PurchAQM_Extension
{
    boolean AQMmustUpdateBatchInfo()
    {
        return true;
    }

}

Вызов (COC):

[ExtensionOf(tableStr(InventBatch))]
final class InventBatchAQM_Extension
{
    public void initFromInventMovement(InventMovement _inventMovement, InventTrans _inventTrans)
    {
        next initFromInventMovement(_inventMovement, _inventTrans);

        if (_inventMovement.AQMmustUpdateBatchInfo())
        {
            // blablabla
        }
    }

В realtime передаю в _inventMovement InventMov_Purch и ожидаю, что вызовется AQMmustUpdateBatchInfo() у экстеншена InventMov_PurchAQM_Extension. Однако вызов происходит у InventMovementAQM_Extension (параметр объявлен как InventMovement)

Если сделать явное преобразование

InventMov_Purch invMov;
        invMov = _inventMovement;
        if (invMov.AQMmustUpdateBatchInfo())
        {
        }

То будет вызов как я ожидаю.

Как Вы считаете - это баг? В 8.1\8.1.1\8.1.2 система ведет себя также?

[wojzeh]

Wrapping a base method in an extension of a derived class
The following example shows how to wrap a base method in an extension of a derived class. For this example, the following class hierarchy is used.

class A
{
    public void salute(str message)
    {   
        info(message);
    }
}

class B extends A {}
class C extends A {}

Therefore, there is one base class, A. Two classes, B and C, are derived from A. We will augment or create an extension class of one of the derived classes (in this case, B), as shown here.

[ExtensionOf(classStr(B))]
final class B_Extension
{
    public void salute(str message)
    {
        next salute(message);
        info("B extension");
    }
}

Although the B_Extension class is an extension of B, and B doesn't have a method definition for the salute method, you can wrap the salute method that is defined in the base class, A. Therefore, only instances of the B class will include the wrapping of the salute method. Instances of the A and C classes will never call the wrapper method that is defined in the extension of the B class.

This behavior becomes clearer if we implement a method that uses these three classes.

class ProgramTest 
{
    public static void main(Args args)
    {
        var a = new A();
        var b = new B();
        var c = new C();

        a.salute("Hi");
        b.salute("Hi");
        c.salute("Hi");
    }
}

For calls to a.salute(“Hi”) and c.salute(“Hi”), the Infolog shows only the message “Hi.” However, when b.salute(“Hi”) is called, the Infolog shows “Hi” followed by “B extension.”

By using this mechanism, you can wrap the original method only for specific derived classes.

https://docs.microsoft.com/en-us/dyn...d-wrapping-coc

[malex]

Цитата:

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

Wrapping a base method in an extension of a derived class
The following example shows how to wrap a base method in an extension of a derived class. For this example, the following class hierarchy is used:

Здравствуйте, wojzeh. Спасибо за ответ. У меня немного другая ситуация: у меня нет COC, но есть extension для базового класса и extension для наследника. Если переменная объявлена как базовый класс, но в realTime инициализируется как наследник, то extension все равно вызывается для базового класса.
(Thank you for your answer. I have the different case: I havn't COC. I have extensions for parent class and for a child. Both extensions has the same method. A class variable declared as a parent class, but initialized as a child. The system invokes extension for the parent class)

class A
{
}
class B extends A
{
}
[ExtensionOf(classStr(A))]
final class A_Extension
{
    public void salute()
    {
        info("A extension");
    }

}
[ExtensionOf(classStr(B))]
final class B_Extension
{
    public void salute()
    {
        info("B extension");
    }

}

class Test01
{        
    public static void main(Args _args)
    {    
        A a;

        a = new B(); 

        a.salute();
    }

}

В результате получим "A extension".

[wojzeh]

технически у тебя два разных класса: исходный и его расширения. очевидно невозможно перекрывать методы расширений (они ж final) ни в классах наследниках, ни в их, наследниках, расширениях. поэтому, строго говоря, это вообще два разных метода у тебя, несмотря на то, что имена у них одинаковы.

если бы расширение класса-наследника "видело" все добавленные во всех расширениях методы класса-родителя, то потребовалось бы вызывать next. и наоборот, если бы расширенные методы класса-родителя трактовались как "родные", они были бы доступны к перекрытию, но ты не можешь вызвать super во втором методе.

так что IS и AS твои друзья тут

[malex]

Цитата:

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

так что IS и AS твои друзья тут

Я так и поступил, но надеялся что это был workaround. Придется почти весь код из наследников переносить в родительский классы с кучей кейсов.

PS: Я все таки думал что на уровне своих методов в экстеншенах будет наследование. А то получается мы у себя в МС будем использовать наследование и override, а вы со своими ISV решениями мучайтесь как хотите и плевать что архитектура внутри у вас будет не очень и с кучей дублирования кода.

[fed]

Цитата:

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

Я так и поступил, но надеялся что это был workaround. Придется почти весь код из наследников переносить в родительский классы с кучей кейсов.

PS: Я все таки думал что на уровне своих методов в экстеншенах будет наследование. А то получается мы у себя в МС будем использовать наследование и override, а вы со своими ISV решениями мучайтесь как хотите и плевать что архитектура внутри у вас будет не очень и с кучей дублирования кода.

А не думали над таким подходом:
1. Определить свои классы как наследники inventMov_purch, inventMov_Sales и тп
2. Переопределить с помощью CoC метод inventMovement::constructNoThrow(), так чтобы он возвращал экземпляры своих классов, вместо стандартных ?

[belugin]

Может я глупость скажу, но в исходном примере final class InventMovementAQM_Extension то есть эктеншены это два не связанных между собою типа и добавляют два несвязанных между собой метода. Вы пробовали унаследовать один от другого?

[wojzeh]

Макс, это не глупость, а именно то же, что уже сказал я. Раз нас уже двое, то мы не можем ошибаться!

[belugin]

Цитата:

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

Макс, это не глупость, а именно то же, что уже сказал я. Раз нас уже двое, то мы не можем ошибаться!

Я имел ввиду, что, может, достаточно сделать их наследниками (но, соответственно, получается что от фреймворка требуется соблюдения правила что подкласс вытесняет суперкласс из экстешненов, а соблюдается ли оно, я не знаю)

[wojzeh]

как это ты их сделаешь наследниками?

[belugin]

Цитата:

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

как это ты их сделаешь наследниками?

Вернее, одного вылечить от бездетности, а второго сделать наследником.

// remove "final"
class InventMovementAQM_Extension
...

// add "extends"
final class InventMov_PurchAQM_Extension extends InventMovementAQM_Extension
...

[ax_mct]

Тут кстати есть где сконфьюзиться

Цитата:

the classes that inherit from a class that has extensions inherit the methods that are defined in the extension classes.

https://docs.microsoft.com/en-us/dyn...ass-extensions

Концепция эффективного класса. Причем эта "сборка" еще зависит от включенных моделей. Как я понимаю extension это не про "extend", а про "add".

The effective class concept

[ax_mct]

Важно что это на самом деле class augmentation (приращение) просто они для красного словца используют class extension

Цитата:

The functionality for class extension, or class augmentation,

[belugin]

Ну да. Сам не пробовал, но интересно, что получится.

[wojzeh]

ничего не получится!

любой extension - это final, а final - это кастрат, у которого наследников в принципе не бывает.

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

[kair84]

Прошу прощение за Офтоп, У меня недавно возникла необходимость сделать подобное, и все получилось, не так красиво как я бы хотел но все же:

class A
{
}
class B extends A
{
}
[ExtensionOf(classStr(A))]
final class A_Extension
{
    public void salute()
    {
        switch (true)
        {
            case this is B:    
                B b = this ;
                b.salute();
            default :
                info("A extension");
        }        
    }
}
[ExtensionOf(classStr(B))]
final class B_Extension
{
    public void salute()
    {
        info("B extension");
    }

}

В идеале хотелось бы обойтись без упоминания конкретного наследника, через DictClass или что то подобное, но пока только так получилось.

[kair84]

Нет, это не Офтоп.... как то по другому называется

[sukhanchik]

Цитата:

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

Прошу прощение за Офтоп, У меня недавно возникла необходимость сделать подобное, и все получилось, не так красиво как я бы хотел но все же:

Знаю. Добивался этого же. Это по сути эмуляция наследования.
Какие в этом случае всплывают проблемы:
1. (Основная). Очевидно, что это работает только для новых методов. Т.е. нельзя в классе А сделать расширение стандартного метода (с использованием метода next), потому что next не позволяет себя вызывать "по условию". Точнее сделать-то можно, вот только когда сделаешь - получается, что можно было сделать проще без этих "выкрутасов".
2. (Организационная). Каждый разработчик должен будет этот "стиль" поддерживать при добавлении нового метода.
3. (Организационная). При наличии нескольких расширений одного класса - они формально могут применяться в любой последовательности. Следовательно код можно писать только такой, который не будет зависеть от последовательности вызова разных расширений.

Т.е. да, чисто академически - так можно написать. Но реально претворить это в жизнь.... весьма сложно, а главное - относительно без особой выгоды.

[ТРЕНЕР]

Цитата:

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

При наличии нескольких расширений одного класса - они формально могут применяться в любой последовательности.

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

[kair84]

Цитата:

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

Знаю. Добивался этого же. Это по сути эмуляция наследования.
Какие в этом случае всплывают проблемы:
1. (Основная). Очевидно, что это работает только для новых методов. Т.е. нельзя в классе А сделать расширение стандартного метода (с использованием метода next), потому что next не позволяет себя вызывать "по условию". Точнее сделать-то можно, вот только когда сделаешь - получается, что можно было сделать проще без этих "выкрутасов".
2. (Организационная). Каждый разработчик должен будет этот "стиль" поддерживать при добавлении нового метода.
3. (Организационная). При наличии нескольких расширений одного класса - они формально могут применяться в любой последовательности. Следовательно код можно писать только такой, который не будет зависеть от последовательности вызова разных расширений.

Т.е. да, чисто академически - так можно написать. Но реально претворить это в жизнь.... весьма сложно, а главное - относительно без особой выгоды.

Согласен, ограничения есть, но часть вами перечисленного относится к принципиальным ограничениям разработки в D365FO в целом. Ax7 сплошные ограничения и танцы с бубном, много чего нужно учитывать.
Вопрос в том что это возможно, а иногда и единственный правильный вариант.

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