[gl00mie]

Цитата:

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

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

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

Цитата:

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

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

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