Оба шаблона имеют одну и ту же необходимость: скрыть от некоторого клиентского кода логику построения сложного объекта. Но что делает «сложным» (или иногда усложняющим) объект? Главным образом, это связано с зависимостями, точнее состоянием объекта, состоящего из более частичных состояний. Вы можете ввести зависимости с помощью конструктора, чтобы установить начальное состояние объекта, но объекту может потребоваться много из них, некоторые будут в исходном состоянии по умолчанию (просто потому, что мы должны были узнать, что установка зависимости по умолчанию на ноль - не самый чистый способ ) и некоторый другой набор в состояние, управляемое некоторым условием. Более того, существуют свойства объекта, которые являются своего рода «забывчивыми зависимостями», но также они могут принимать необязательные состояния.
Есть два хорошо известных способа преодоления этой сложности:
Состав / агрегация: построить объект, построить его зависимые объекты, а затем соединить вместе. Здесь конструктор может сделать прозрачным и гибким процесс, который определяет правила, определяющие конструкцию компонента.
Полиморфизм: правила построения объявляются непосредственно в определении подтипа, поэтому у вас есть набор правил для каждого подтипа, и некоторые условия решают, какое из этих правил применимо для построения объекта. Завод идеально подходит для этого сценария.
Ничто не мешает смешать эти два подхода. Семейство продуктов может абстрагироваться от создания объекта, выполненного с помощью компоновщика, а компоновщик может использовать фабрики для определения того, какой компонент компонента создается.