mfp: SysExtension Framework – to the rescue

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

[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

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

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

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