Factory Method: стандартизированное создание объектов
Factory Method инкапсулирует создание объектов за интерфейсом фабричного метода, убирая из клиентского кода прямые вызовы конструкторов. Вместо того чтобы создавать объекты явно, клиент обращается к фабрике или абстрактному методу, который возвращает готовый экземпляр нужного типа.
Паттерн особенно полезен, когда тип создаваемого объекта должен определяться не клиентом, а конфигурацией, контекстом, параметрами или конкретной реализацией подкласса. Это снижает связанность и позволяет расширять систему новыми типами, не меняя вызывающий код.
Factory Method широко используется в фреймворках, DI контейнерах, ORM, драйверах, интеграциях, слоях доступа к данным и при проектировании архитектуры плагинов.
Factory Method считается одним из фундаментальных паттернов, потому что практически в каждой современной системе объекты не создаются напрямую через конструктор, а появляются через некий фабричный слой. Это может быть статический метод, фабричный класс, метод интерфейса, фабрика в DI контейнере, фабрика внутри ORM или инфраструктурный компонент. С точки зрения архитектора, фабричный метод — это способ убрать знание о конкретном классе из клиентского кода и заменить его знанием о контракте: клиент ожидает объект с определенным интерфейсом, а фабрика решает, какой конкретный тип вернуть.
Классический сценарий: у нас есть абстракция, например, интерфейс PaymentClient. Существуют разные реализации для разных банков, провайдеров или сред (тестовая, боевая). Клиенту не хочется держать в коде new SberPaymentClient() или new TinkoffPaymentClient(). Вместо этого он вызывает фабричный метод PaymentClient create(...), который по параметрам конфигурации (тип банка, регион, окружение) или по контексту (фича-флаг, среда исполнения) возвращает нужную реализацию. При добавлении нового банка меняется только фабрика, но не весь код, который пользуется платежным клиентом. Это существенно снижает стоимость изменений и облегчает эволюцию архитектуры.
Factory Method тесно связан с принципом инверсии зависимостей: вместо того чтобы высокоуровневый модуль сам решал, какой конкретный класс создавать, он работает с абстракцией, а решение о конкретном типе переносится в фабрику или DI контейнер. В архитектуре это позволяет оформлять создание объектов в виде явного слоя: фабрики для репозиториев, клиентов внешних систем, адаптеров, стратегий, обработчиков команд, коннекторов к брокерам сообщений. В системах с плагинами фабричный метод часто используется в сочетании с механизмен регистрации: новые реализации добавляются путем регистрации в фабрике, после чего клиентский код начинает их использовать без изменений.
Важно понимать, что фабричный метод может быть как отдельным объектом (класс фабрики), так и абстрактным методом базового класса, который переопределяется в наследниках. Во втором случае часто получают иерархию, где каждый подкласс создает свои конкретные продукты. Это удобно, когда создание объекта тесно связано с логикой подкласса или когда для каждой конфигурации подсистемы нужны собственные варианты продуктов. Архитектор решает, использовать ли фабрику как отдельный объект (более модульный подход) или как часть иерархии (классический GoF вариант).
В современных фреймворках фабричный метод часто встроен в инфраструктуру: в DI контейнерах фабрики скрыты за механизмом container.resolve(Type), в ORM фабричные методы прячутся за вызовами Create, Attach, FromDatabase, в сетевых библиотеках — за методами создания клиентов, коннекторов, сторов сессий. При проектировании архитектуры важно осознанно вводить фабрики для тех элементов, где ожидается смена реализаций: например, хранилища данных, интеграционные клиенты, стратегии маршрутизации, политики кеширования, механизмы ретраев, форматы логирования. Это позволяет системе эволюционировать без повсеместного рефакторинга.
С точки зрения учебных программ по архитектуре ИС фабричный метод рассматривается не как локальный «трюк», а как базовый организационный механизм: он помогает отделить архитектурные решения о том, какие компоненты вообще существуют в системе, от прикладного кода, который пользуется этими компонентами. Таким образом, Factory Method поддерживает модульность, расширяемость и управляемость архитектуры, а его понимание является обязательным для архитектора, который проектирует систему с долгим жизненным циклом и неоднократной сменой технологий.