D365FO: Inheritance + Extensions + RealTime

[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 сплошные ограничения и танцы с бубном, много чего нужно учитывать.
Вопрос в том что это возможно, а иногда и единственный правильный вариант.

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