Я имею в виду шаблоны GoF Abstract Factory и Factory Method. Я понимаю их цель, но что меня беспокоит, так это то, что оба шаблона опускают обсуждение того, как клиент получает экземпляр «фабричного объекта». Например, в следующем шаблоне абстрактная фабрика обсуждение предполагает, что какая-то другая платформа или код драйвера уже построили иерархию, и что экземпляр Application уже содержит экземпляр GUIFactory (либо WinFactory, либо OSXFactory).
(источник: https://en.wikipedia.org/wiki/Abstract_factory_pattern) 
Аналогичный аргумент относится к шаблону Factory Method. Обсуждение предполагает, что что-то еще снаружи уже создало экземпляр MagicMazeGame.
(источник: https://en.wikipedia.org/wiki/Factory_method_pattern) 
Почему меня это беспокоит? Потому что нам нужен другой шаблон для построения этих иерархий объектов, и именно этот шаблон на самом деле имеют в виду многие люди, когда говорят Factory. В основном заводской шаблон выглядит следующим образом:
(источник: Domain Driven Design, Эрик Эванс, 2003 г.) 
На мой взгляд, это отличный шаблон от Abstract Factory или Factory Method. Клиент указывает требования, а фабрика создает объекты на основе требований, а также на основе конфигурации и контекста. В качестве гипотетического примера клиент указывает, что ему нужен абстрактный объект Connection, фабрика создает MySQLConnection или OracleConnection в зависимости от драйвера базы данных, настроенного в системе.
Итак, мои вопросы:
- есть термин для последнего шаблона, который я описал? (Я пытался исследовать, но термин фабрика всегда означает фабричные шаблоны в GoF)
- как должна называться фабрика, которая создает фабрики?
GUIFactoryFactory??? - или я совсем не прав во всем этом?
Я знаю, что этот вопрос касается только того, как называть вещи, но использование вездесущего языка (источник: Domain Driven Design, Eric Evans 2003. И я полностью согласен) также очень важно в разработке программного обеспечения в мое мнение.
