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. Ну если только захотели бы свои параметры добавлять.