Сначала несколько общих вещей, чтобы следовать моей аргументации:
Основная проблема при разработке больших программных систем заключается в том, что они должны быть гибкими и несложными для изменения. По этой причине существуют некоторые показатели, такие как сцепление и сплоченность. Чтобы создать системы, которые можно легко изменять или расширять по функциональности без необходимости перепроектирования всей системы с нуля, вы можете следовать принципам проектирования (например, SOLID и т. Д.). Через некоторое время некоторые разработчики осознали, что, если они следуют этим принципам, есть некоторые похожие решения, которые хорошо работают для подобных проблем. Этими стандартными решениями оказались шаблоны проектирования.
Таким образом, шаблоны проектирования должны помочь вам следовать общим принципам проектирования для достижения слабосвязанных систем с высокой когезией.
Ответ на вопрос:
Задавая разницу между двумя шаблонами, вы должны спросить себя, какой шаблон делает вашу систему более гибкой. У каждого шаблона есть своя цель - организовать зависимости между классами в вашей системе.
Абстрактный шаблон фабрики:
GoF: «Предоставить интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных классов».
Что это значит:
Предоставляя такой интерфейс, вызов конструктора каждого продукта семейства инкапсулируется в фабричном классе. И поскольку это единственное место во всей вашей системе, где вызываются эти конструкторы, вы можете изменить свою систему, внедрив новый класс фабрики. Если вы обмениваетесь представлением фабрики через другого, вы можете обмениваться целым набором продуктов, не затрагивая большую часть своего кода.
Образец строителя:
GoF: «Отделите построение сложного объекта от его представления, чтобы один и тот же процесс построения мог создавать разные представления».
Что это значит:
Вы инкапсулируете процесс построения в другом классе, называемом директором (GoF). Этот директор содержит алгоритм создания новых экземпляров продукта (например, составление сложного продукта из других частей). Для создания составных частей всего продукта директор использует застройщика. Обменив конструктор с директором, вы можете использовать тот же алгоритм для создания продукта, но изменить представления отдельных частей (и, следовательно, представление продукта). Чтобы расширить или изменить свою систему в представлении продукта, все, что вам нужно сделать, это реализовать новый класс компоновщика.
Итак, вкратце:
Цель Abstract Factory Pattern - обменяться набором продуктов, которые предназначены для совместного использования. Цель шаблона построителя состоит в том, чтобы инкапсулировать абстрактный алгоритм создания продукта, чтобы повторно использовать его для различных представлений продукта.
По-моему, вы не можете сказать, что Шаблон Абстрактной Фабрики - старший брат Шаблона Строителей. ДА, они оба являются творческими шаблонами, но основная цель шаблонов совершенно иная.