Я думаю, что есть место для абстрактного шаблона фабрики, а не простого шаблона фабрики в местах, где ваши экземпляры очень сложны, слишком сложны и уродливы для одной фабрики и слишком сложны для понимания пользовательского интерфейса.
Допустим, это бренд TYPE_A, а не отдельный класс ... предположим, что существует семейство из 100 подобных классов Type-A, и вам нужно создать экземпляр одного объекта из них. Представьте, что существует подробная сложная информация, необходимая для того, чтобы сделать правильный объект из множества объектов аналогичного типа, и в этой сущности объекта вам нужно точно знать, какие параметры настраивать и как их настраивать.
На специальной фабрике для этого бренда мы попросим их дифференцировать и получить точный объект для создания экземпляра, а также способы его создания. мы узнаем это в соответствии с вводом из сети (допустим, какой цвет доступен в интернет-магазине), а также от других приложений и служб, работающих в фоновом режиме (параметры, которые пользовательский интерфейс не знает).
И, возможно, завтра у нас будет еще одно семейство, скажем, type_B и type_C, для создания экземпляра. Таким образом, пользовательский интерфейс будет иметь «if else», чтобы знать, хочет ли пользователь «type_A», «type_B» или «type_C» - но классы фабрик будут решать, какой именно класс из типа (из семейства) строить, и как его настроить - какие значения задать его параметрам или отправить его исполнителю. Все это - по многим параметрам, о которых пользовательский интерфейс не знает. Все это будет слишком много для одного фабричного класса.