Template Method нарушает базовые принципы ООП
А вы обратили внимание, что паттерн Template Method нарушает один из базовых принципов ООП? Я говорю о модульности системы (Гради Буч, «ООАиП», гл.2: «Модульность – это свойство системы, которая была разложена на внутренне связные, но слабо связанные между собой модули»).
В теории считается, что модуль не должен знать о контексте, в котором он используется – это обеспечивает высокий коэффициент его reusability. В ООП-языках нет базовых средств, позволяющих библиотеке или серверу статически (во время компиляции) контролировать реализацию клиента, налагать на неё (синтаксические и семантические) ограничения. С точки зрения ООП, это плюс, потому что серверу и клиенту не должно быть дела до реализации друг друга.
Однако на практике библиотеки и серверные классы часто нуждаются, например, в определенном порядке инициализации со стороны клиента. В этом случае мы можем предоставить клиенту абстрактный класс Base, который реализует паттерн Template Method. Клиент должен унаследовать класс Base и конкретизировать его чисто виртуальные методы, вызываемые из Template Method. В классе-наследнике Template Method насыщается плотью и кровью реальных директив.
Альтернатива: можно создать Abstract Factory, которая для клиентского класса проведет всю сложную сборку и инициализацию сервера. Но это лишает клиента гибкости в настройке сервера.
Anyway, паттерн Template Method – весьма остроумный и изощренный, кстати – нарушает базовые принципы ООП. Тем хуже для базовых принципов! И это не единственный паттерн такого рода. Если мы хотим, чтобы клиентский класс использовал только n экземпляров библиотечного класса, то мы используем Singleton. Насчет него
_winnie вчера сформулировал очень точный вопрос: «Почему Singleton сам решает, что он должен быть в единственном экземпляре, а не код который использует Singleton?» Согласитесь, это нарушение принципа модульности. Но, конечно, сервер должен накладывать свои ограничения на клиентский код. В отношении клиентского кода не работает презумпция правильности.
В теории считается, что модуль не должен знать о контексте, в котором он используется – это обеспечивает высокий коэффициент его reusability. В ООП-языках нет базовых средств, позволяющих библиотеке или серверу статически (во время компиляции) контролировать реализацию клиента, налагать на неё (синтаксические и семантические) ограничения. С точки зрения ООП, это плюс, потому что серверу и клиенту не должно быть дела до реализации друг друга.
Однако на практике библиотеки и серверные классы часто нуждаются, например, в определенном порядке инициализации со стороны клиента. В этом случае мы можем предоставить клиенту абстрактный класс Base, который реализует паттерн Template Method. Клиент должен унаследовать класс Base и конкретизировать его чисто виртуальные методы, вызываемые из Template Method. В классе-наследнике Template Method насыщается плотью и кровью реальных директив.
Альтернатива: можно создать Abstract Factory, которая для клиентского класса проведет всю сложную сборку и инициализацию сервера. Но это лишает клиента гибкости в настройке сервера.
Anyway, паттерн Template Method – весьма остроумный и изощренный, кстати – нарушает базовые принципы ООП. Тем хуже для базовых принципов! И это не единственный паттерн такого рода. Если мы хотим, чтобы клиентский класс использовал только n экземпляров библиотечного класса, то мы используем Singleton. Насчет него
_winnie вчера сформулировал очень точный вопрос: «Почему Singleton сам решает, что он должен быть в единственном экземпляре, а не код который использует Singleton?» Согласитесь, это нарушение принципа модульности. Но, конечно, сервер должен накладывать свои ограничения на клиентский код. В отношении клиентского кода не работает презумпция правильности. 