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