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