Myślę, że jest miejsce na abstrakcyjny wzorzec fabryki zamiast prostego wzorca fabryki w miejscach, w których Twoje instancje są bardzo skomplikowane, zbyt skomplikowane i brzydkie dla pojedynczej fabryki i zbyt skomplikowane, aby interfejs użytkownika mógł je pojąć.
Powiedzmy, że jest to marka TYPE_A, a nie pojedyncza klasa ... powiedzmy, że istnieje rodzina 100 rodzajów podobnych klas typu A i musisz utworzyć z nich jeden obiekt. Wyobraź sobie, że istnieje szczegółowa, wyrafinowana informacja potrzebna do stworzenia właściwego obiektu z marki wielu podobnych typów obiektów, aw tej encji obiektu musisz dokładnie wiedzieć, które parametry należy dostroić i jak je dostroić.
W specjalnej fabryce dla tej marki będziemy musieli rozróżniać i pobierać dokładny obiekt do utworzenia wystąpienia, a także sposób jego utworzenia. będziemy wiedzieć, że na podstawie danych wejściowych z sieci (powiedzmy, jaki kolor jest dostępny w sklepie internetowym) oraz z innych aplikacji i usług działających w tle (parametry, których UI nie zna).
A może jutro będziemy mieć inną rodzinę, powiedzmy type_B i type_C, do utworzenia instancji. Więc interfejs użytkownika będzie miał „jeśli jeszcze”, aby wiedzieć, czy użytkownik chce „typ_A”, „typ_B” lub „typ_C” - ale klasy fabryk zdecydują dokładnie, którą klasę z typu (z rodziny) zbudować, i jak go dostroić - jakie wartości ustawić na jego parametry lub wysłać do kontrahenta. Wszystko to - według wielu parametrów, których interfejs użytkownika nie jest świadomy. To wszystko będzie za dużo dla jednej klasy fabryki.