Я нашел тот же вопрос очень интересным.
Пример автомобиля Saab интересен, но он не соответствует описанию шаблона Builder в «Банде четырех» (Design Patterns).
Я буду использовать терминологию «Банды четырех».
В «Банде четырех» не может быть смеси бетоностроителей на каждый вызов aDirector->Construct(), поэтому пример Saab, хотя и интересен, не отвечает на вопрос действительно для меня.
Я вижу некоторые:
Отделение объекта Director от иерархии построителя является ключевым отличием. В фабрике шаблонов и метод, который воплощает обобщенный поток, и переопределенные методы являются членами одного класса. Это делает паттерн Builder лучше при инкапсуляции внутренних этапов процесса, поскольку клиентский код с меньшей вероятностью вступит в контакт с такими методами, если получит доступ только к объекту Director. Шаблон компоновщика также позволяет формулировать процесс сборки полностью независимо от иерархии компоновщика, что позволяет более гибко заменять экземпляр компоновщика при необходимости. Например, имея под рукой экземпляр директора, вы можете легко построить несколько представлений продукта, каждый раз динамически заменяя конструктор бетона. Таким образом, строитель более динамичен и лучше заполняет внутреннюю работу бетонщика.
Кроме того, если вы хотите уточнить объект Director по наследованию, вы можете сделать это, не увеличивая свою иерархию. Например, у вас может быть ускоренный процесс построения для экономии времени перед окончательным построением - вы можете создать подкласс объекта Director или даже использовать «шаблонный метод» сам по себе, чтобы настроить его по наследству без необходимости переопределения ваших конкретных конструкторов.
Но это приводит нас к рассмотрению другого паттерна, тесно связанного с «Фабрикой шаблонов» - паттерном «Стратегия».
Стратегия очень похожа на фабрику шаблонов, с двумя очевидными отличиями: она также отделяет объект Context от иерархии Strategy, позволяя переключать алгоритмы для одного экземпляра задачи во время выполнения. Другое отличие состоит в том, что примеры, по-видимому, предполагают, что использование Стратегии не обязательно предполагает сложный или структурированный процесс, как в «Методе шаблона».
Но я привожу его здесь в качестве аналога Builder, чтобы перейти к другому моменту - если «Стратегия» параллельна в своей структуре классов с Builder, то параллельный образец создания «Template Method» должен быть «Factory Method». Это понятно не только по названию, но и достаточно интересно, что в обеих главах книги «Метод фабрики» и «Метод шаблона» используются почти идентичные примеры (приложение для редактирования документов).
Итак, не вдаваясь в вопрос о том, в чем разница между творческим и поведенческим паттернами, я склонен думать, что и Строитель, и Фабричный метод - это в основном конкретные случаи и уточнения Стратегии и Шаблонного метода, соответственно.
Таким образом, возникает вопрос - если вы не видите разницы между Builder и Template Factory - попробуйте ответить на следующие вопросы:
Какую перспективу вы предпочитаете иметь в этой конкретной части системы? Это «поведение» или «создание»? и
Требуется ли вам сильная инкапсуляция или динамическая замена, развертывание или настройка экземпляра компоновщика, с одной стороны, или вы ожидаете, что сложность (наследование, композиция или иное) будет развиваться вокруг процесса создания или шаблонный метод? Если ответ на любой из этих вопросов идет со структурой Строитель / Стратегия. В противном случае, используйте простой полиморфизм отношения или поведения в шаблонах метода XX.