mfp: SysExtension Framework – to the rescue

[Blog bot]

Источник: http://blogs.msdn.com/b/mfp/archive/...he-rescue.aspx
==============
There is a coding pattern that has been proliferating the X++ code base for years. It is not an X++ best practices – nor is it object oriented; yet it is used quite heavily (unfortunately). Consider a simple class hierarchy with an abstract base class and 3 derived classes. A typical implementation of a factory would be a static method on the base class, like this: (Please ignore the type of the parameter – it could  be anything, I choose str for simplicity)



Now; the problems with this approach are many.

• First of all the base class has references to the sub classes. Why is that a problem? Consider the base class is a framework class – is it a good idea for framework classes to have references to consumer classes of the framework? Of course not – we don’t like that coupling.
• Secondarily; the 3 subclasses are all referenced by the same method. Any new sub class would require an update to the factory. This turns the method into a congestion point, and it creates a coupling between sub-classes.

The coupling between the 4 classes spells trouble. If you try to modularize an application written like this, you will quickly realize that the pattern above is bad. You cannot have references from lower-level models (aka. assemblies/modules) to higher-level models. Yet; having a single factory method is valuable and a good practice.

SysExtension Framework to the rescue.

Consider you decorate the subclasses with an attribute, like depicted here:



Then you can rewrite the factory method to this:



The extension framework returns an instance of the right subclass automatically. It uses the attribute to determine which subclass instance to create. Quite simple – extraordinary powerful!

Now notice:

• Truly decoupled! New subclasses can be added without any changes to the base class.
• Less code is required! In the example here the delta is not significant – but sometimes you have switch statements spanning hundreds of lines.
• No change in the public API! The contract stays the same – this is an easy and low risk refactoring.

A few words of caution: There is a small performance impact on cold systems when using the SysExtension framework. In most cases you will not notice it; however – for performance critical paths, you should measure the impact of this change before going for it.

To learn more about the SysExtension framework see here.




==============
Источник: http://blogs.msdn.com/b/mfp/archive/...he-rescue.aspx

[Logger]

Интересная статья.

Но по-моему выгоды от предлагаемого подхода совсем неочевидны.
Что сделал mfp ?
Просто вынес код-создатель нужного наследника из конструктора в базовом классе в некий классфактори. По сути тоже самое. И ссылки из базового класса в наследники все равно по смыслу остались. Просто мы их на красивых схемах UML не увидим (од тех пор пока не нарисуем там еще и SysExtensionAppClassFactory ).

Вместо ссылок из BaseClass к наследникам, мы увидим кучу ссылок из SysExtensionAppClassFactory к тем же наследникам. Сложность системы и число взаимных связей не уменьшилось ! Просто замели под половичок...

А если предположить (судя по названию) что класс SysExtensionAppClassFactory будет использоваться не только для создания наследников BaseClass, но и других классов, то получится вообще катастрофа. Мы получили мегаконструктор, который содержит ссылки на кучу классов. Никакого упрощения не видно. Только красота отдельных кусков UML-схем.

Цитата:

Truly decoupled! New subclasses can be added without any changes to the base class.

Да, но кому от этого легче ? Ведь SysExtensionAppClassFactory все равно придется менять. Польза может быть только если BaseClass потребуется прятать в сборку с закрытым исходным кодом. Может это и есть конечная цель всех изменений?

Цитата:

Less code is required! In the example here the delta is not significant – but sometimes you have switch statements spanning hundreds of lines.

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

Цитата:

No change in the public API! The contract stays the same – this is an easy and low risk refactoring.

Может и так но исходный вариант с конструктором не предполагал изменение API. Ну если только захотели бы свои параметры добавлять.

[gl00mie]

Цитата:

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

Да, но кому от этого легче ? Ведь SysExtensionAppClassFactory все равно придется менять.

Да нет же, ни в коем случае! Смысл как раз в том, что каждый статический метод-"фабрика" в базовом классе той или иной иерархии должен знать всех наследников уже во время компиляции - именно поэтому его постоянно приходится менять при добавлении новых наследников. А "фабрика" SysExtension во время компиляции ничего ни про кого не знает - она получает всю необходимую информацию о классах-наследниках во время выполнения, узнает, какое значение какого атрибута сопоставлено какому наследнику, и уже исходя из этого создает экземпляр нужного класса из иерархии для заданного значения атрибута. Эта информация, разумеется, кэшируется, причем в 2012-й появился глобальный кэш на уровне АОСа (т.е. разделяемый между всеми сессиями). Но основной смысл в том, что ни код базового класса, ни код "фабрики" никак не меняется при создании очередного класса-наследника.

Цитата:

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

Цитата:

No change in the public API! The contract stays the same – this is an easy and low risk refactoring.

исходный вариант с конструктором не предполагал изменение API.

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

[Logger]

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

Как быть в данном случае теперь? Если у нас все однозначно определяется атрибутом, то получается что мы заданием атрибута жестко фиксируем конкретного наследника.

Т.е. чтобы повторить вышеописанный финт, придется менять кучу мест коде ?
Или теперь надо действовать как-то иначе ?
Или внесение кастомизаций в Классфактори не запрещено, так что мы для переданного значения атрибута все же сможем подсунуть другого наследника ?

Кстати, неявная связь - атрибут - наследник все равно есть. Перекрестные ссылки её позволяют отследить ?

[mazzy]

Цитата:

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

Но по-моему выгоды от предлагаемого подхода совсем неочевидны.
Что сделал mfp ?... Просто замели под половичок

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

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

[gl00mie]

Цитата:

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

раньше можно было в зависимости от каких-то условий (например от параметров в настроечной табличке), сгенерить другого наследника. Как быть в данном случае теперь? Если у нас все однозначно определяется атрибутом, то получается что мы заданием атрибута жестко фиксируем конкретного наследника.

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

Цитата:

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

Или внесение кастомизаций в Классфактори не запрещено, так что мы для переданного значения атрибута все же сможем подсунуть другого наследника ?

Теоретически можно покорежить фабрику SysExtension, но это порушит всю идею. Это все равно что в код зашивать

if (trans.AccountNum == "ИП Пупкин") {...} else {...}

Цитата:

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

Кстати, неявная связь - атрибут - наследник все равно есть. Перекрестные ссылки её позволяют отследить?

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

Цитата:

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

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

По-моему, это зависит от того, где располагается точка принятия решения: если клиентский код сам не знает, чего хочет, и решение отдано на откуп "умному" методу-фабрике, который неочевидным образом выбирает нужный подкласс, тогда да, указанный подход не работает, потому что фабрика SysExtension лишена искуственного интеллекта и знаний, специфичных для той или иной иерархии классов. Если же у клиентского кода есть ясность относительно того, что он хочет получить, то таких проблем не возникает.

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

Цитата:

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

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

Как мне представляется, есть определенная проблема, даже две:

• сложность подъема кастомизаций при обновлении (сюда относится и накатывание обновлений стандартного приложения, и перенос модификаций на новый SP/CU/Rollup)
• сложность скрещивания разных решений в одном слое

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

[Logger]

Цитата:

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

По-моему, это зависит от того, где располагается точка принятия решения: если клиентский код сам не знает, чего хочет, и решение отдано на откуп "умному" методу-фабрике, который неочевидным образом выбирает нужный подкласс, тогда да, указанный подход не работает, потому что фабрика SysExtension лишена искуственного интеллекта и знаний, специфичных для той или иной иерархии классов. Если же у клиентского кода есть ясность относительно того, что он хочет получить, то таких проблем не возникает.

Но ведь это эквивалентно тому что мы явно напишем в коде New ClassNameXXX()
Гибкость теряется.
Вся прелесть в том и была чтобы можно было подправив только конструктор, заставить кучу кода работать по-другому.
См. пример с использованием семейства SysExcel и ComExcelDocument_RU и проблемами которые это повлекло, когда захотели везде в иерархии подменить использование этих классов на наследников работающих через .Net

В такой новой схеме на ax2012 как бы ты реализовал эту задачу ? Может быть есть удобный и красивый вариант ?

[gl00mie]

Цитата:

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

Но ведь это эквивалентно тому что мы явно напишем в коде New ClassNameXXX() Гибкость теряется. Вся прелесть в том и была чтобы можно было подправив только конструктор, заставить кучу кода работать по-другому.

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

Цитата:

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

См. пример с использованием семейства SysExcel и ComExcelDocument_RU и проблемами которые это повлекло, когда захотели везде в иерархии подменить использование этих классов на наследников работающих через .Net. В такой новой схеме на ax2012 как бы ты реализовал эту задачу?

ComExcelDocument_RU в коде приложения везде создается через new, т.е. там вообще не предполагается, что у него могут быть наследники. А что касается SysExcel - там немного другая тема: в нем использован шаблон "стратегия" для создания экземпляров классов, и за счет этого оказалось возможным подменить версию, работающую через COM, на версию, работающую через .NET. Шаблон же "фабрики" в нем можно было бы применить для поддержки различных версий офиса в случае работы через COM, а там вместо этого есть жесткая завязка на определенный перечень версий, зашитый в enum.
Т.е. вызывающий код не знает и не должен знать, с какой версией офиса он работает - это заморочки обертки (SysExcel, например). Но сама обертка знает, с какими версиями офиса она умеет работать, и знает это в куче мест, где по енуму MSOfficeVersion создается тот или иной класс-наследник. Если бы была задача научить ее работать с большим числом версий, то в 2012 это отчасти удобнее было бы делать с помощью новой "фабрики".

[EVGL]

Цитата:

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

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

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

Не пойму: вы [вдвоем] лукавите или всерьез? Вас никогда не раздражало, что приходилось перекрывать конструктор базового класса в текущем слое приложения?

[mazzy]

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

бесит как раз "уникальные подходы" в стиле: "сюда смотри, сюда не смотри, здесь рыбу заворачивали"

[belugin]

SysExtension framework одно из средств чтобы было можно написать расширение для системы не меняя кода, а только добавляя его. Другие средства это, например, модели и события.

Это позволяет, например, не мержить код при обновлении.

Конечно, это подходит не для всех случаев, но множественность параметров, например, оно поддерживает.

Мне кажется у части участников форума выработалась привычка к тем способам решения проблем, которые приняты в аксапте а в большой программистский мир они не смотрят. Я бы посоветовал почитать таким участникам про inversion of control и dependency injection так как это - явно следующий шаг.

[belugin]

Цитата:

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

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

"Зачем нужен молоток? Все равно рано или поздно нам встретиться шуруп, и потребуется отвертка, а гвозди мы можем забивать привычным образом, взяв отвертку за другой конец и стуча им по шляпке"

Цитата:

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

бесит как раз "уникальные подходы" в стиле: "сюда смотри, сюда не смотри, здесь рыбу заворачивали"

Тут я согласен - наверное, надо было пересадить на этот Фреймворк как можно больше подходящего кода - вон в source document + distributions свой примерно такой же, никак не связанный с этим

[Logger]

Хотелось бы еще получше понимать как теперь с помощью нового инструмента простым способом
реализовать такое :

Цитата:

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

[gl00mie]

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

[Logger]

Понятно.

Но ведь некоторые проекты внедрения и состоят сплошь из костылей, как какой-нить киношный терминатор убийца
Нельзя же в процессе внедрения поменять всю архитектуру. Приходится скакать в светлое будущее на костылях.
А некоторые к инвалидной тележке моторчик привинтили. Хорошо катается

[belugin]

Цитата:

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

Хотелось бы еще получше понимать как теперь с помощью нового инструмента простым способом
реализовать такое :

- во-первых, можно откатиться к construct и добавить post- event для своего случая
- во-вторых, можно закодировать условие в значение атрибута
- в-третьих, посмотрите на ту надстройку, которая используется в templateprovider_ru - оно поддерживает иерархические атрибуты и условия

[Logger]

Ок.
Спасибо всем.
Посмотрю рекомендованные описания.

[macklakov]

Цитата:

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

- в-третьих, посмотрите на ту надстройку, которая используется в templateprovider_ru - оно поддерживает иерархические атрибуты и условия

Можешь для тупых объяснить, что за хитрая магия в этом классе упрятана? В R3 я вижу один абстрактный класс с одним единственным наследником. Если верить коду, то достаточно было одного static метода, который по строчному параметру ищет ссылки на файлы. Смысл в этом всем?
Вот в BankReconciliationMatchingMatchProcessor.constructMatch смысл ясен. Ребята игрались с toolbox, пробовали все, что под руку попалось. В результате получился конструктор для вызова конструктора, который вызывает фреймворк.

[belugin]

Цитата:

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

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

Когда я переводил отчеты с файловой шары на ресурсы, у меня закралось подозрение, что кто-то, возможно, захочет поменять это дело обратно для каких-то отчетов или реализовать какое-то свое хранилище шаблонов (например, на http server) чтобы дать power users возможность их редактирования без правки aot.

Для того чтобы было легко, не меняя сами отчеты перекрыть для них это хранилище так и сделано. Вторая реализация есть, но она используется для тестирования внутри ms.

[macklakov]

Цитата:

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

Вторая реализация есть, но она используется для тестирования внутри ms.

А как переключение между наследниками происходит? Ну вот предположим захотел я использовать эту внутреннюю, ms-овскую, реализацию.