mfp: SysExtension Framework – to the rescue

[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 это отчасти удобнее было бы делать с помощью новой "фабрики".