Паттерн Фабричный метод (Factory Method)

Суть паттерна

Фабричный метод – это порождающий паттерн проектирования, который определяет общий интерфейс для создания объектов в суперклассе, позволяя подклассам изменять тип создаваемых объектов.

Проблема

Представьте, что вы создаёте программу управления грузовыми перевозками. Сперва вы рассчитываете перевозить товары только на автомобилях. Поэтому весь ваш код работает с объектами класса Truck (грузовик).

В какой-то момент ваша программа становится настолько известной, что морские перевозчики выстраиваются в очередь и просят добавить поддержку морской логистики в программу.

Отличные новости, правда?! Но как насчёт кода? Большая часть существующего кода жёстко привязана к классу Truck. Чтобы добавить в программу классы морских судов, понадобится перелопатить всю программу. Более того, если вы потом решите добавить в программу ещё один вид транспорта, то всю эту работу придётся повторить.

В итоге вы получите ужасающий код, наполненный условными операторами, которые выполняют то или иное действие, в зависимости от класса транспорта.

Решение

Паттерн Фабричный метод предлагает создавать объекты не напрямую, используя оператор new, а через вызов специального фабричного метода. Не пугайтесь, объекты всё равно будут создаваться при помощи new, но делать это будет фабричный метод. Объекты, возвращаемые фабричным методом, часто называют продуктами.

На первый взгляд, это может показаться бессмысленным: мы просто переместили вызов конструктора из одного конца программы в другой. Но теперь вы сможете переопределить в подклассе фабричный метод, чтобы изменить тип создаваемого продукта.

Однако здесь есть небольшое ограничение: подклассы могут возвращать различные типы объектов-продуктов, только если эти объекты имеют общий базовый класс или интерфейс. Кроме того, тип возвращаемого значения для фабричного метода в базовом классе должен быть объявлен как этот интерфейс.

Например, классы Truck (грузовик) и Ship (судно) реализуют интерфейс Transport (транспорт) с методом deliver() (доставить). Каждый из этих классов реализует этот метод по-своему: грузовики везут грузы по земле, а суда – по морю. Фабричный метод в классе RoadLogistic (дорожная логистика) возвращает объекты-грузовики, а класс SeaLogistics (морская логистика) – объекты-суда.

Код, использующий фабричный метод (часто называемый клиентским кодом), не видит разницы между фактическими продуктами, возвращаемыми различными подклассами. Клиент рассматривает все продукты как объекты абстрактного класса Transport (транспорт). Клиент знает, что все объекты Transport должны иметь метод deliver(), но то, как именно он работает, для клиента не имеет значения.

Структура

1. Продукт (Product) определяет общий интерфейс объектов, которые может создать Creator (создатель) и его подклассы.

2. Конкретные продукты содержат код различных продуктов. Продукты будут отличаться реализацией, но интерфейс у них будет общий.

3. Создатель (Creator) объявляет фабричный метод, который должен возвращать новые объекты продуктов. Важно, чтобы тип возвращаемого значения совпадал с общим интерфейсом продуктов.

Зачастую фабричный метод объявляют абстрактным, чтобы заставить все подклассы реализовать его по-своему. Но он может возвращать и некий стандартный тип продукта.

Несмотря на название, важно понимать, что создание продуктов не является единственной функцией создателя. Обычно он содержит и другой полезный код работы с продуктом. Аналогия: большая софтверная компания может иметь центр подготовки программистов, но основная задача компании – создавать программные продукты, а не готовить программистов.

4. Конкретные создатели по-своему реализуют фабричный метод, создавая те или иные конкретные продукты.

Фабричный метод не обязан всё время создавать новые объекты. Его можно переписать так, чтобы возвращать существующие объекты из какого-то хранилища или кэша.

Псевдокод

В этом примере Фабричный метод помогает создавать кросс-платформенные элементы интерфейса, не привязывая основной код программы к конкретным классам элементов.

Базовый класс диалога использует различные элементы пользовательского интерфейса для визуализации своего окна. В разных операционных системах эти элементы могут выглядеть немного по-разному, но они всё равно должны вести себя одинаково. Кнопка в Windows остается кнопкой и в Linux.

Когда в игру вступает Фабричный метод, вам не нужно переписывать логику диалогового окна для каждой операционной системы. Если мы объявим Фабричный метод, который создает кнопки внутри базового диалогового класса, мы можем позже создать подкласс диалога, который из фабричного метода возвращает кнопки в стиле Windows. Затем этот подкласс наследует большую часть кода диалогового окна от базового класса, но, благодаря фабричному методу, может рендерить на экране кнопки в стиле Windows.

Чтобы этот паттерн работал, базовый класс диалогового окна должен работать с абстрактными кнопками: с базовым классом или интерфейсом, которому следуют все конкретные кнопки. Таким образом, код диалогового окна остается рабочим, с каким бы типом кнопок он ни работал.

Конечно, вы можете применить этот подход и к другим элементам пользовательского интерфейса. Однако с каждым новым фабричным методом, который вы добавляете в диалог, вы приближаетесь к паттерну «Абстрактная фабрика». Мы поговорим о нем позже.

// Класс-создатель объявляет фабричный метод, который должен
// возвращать объект класса продукта. Подклассы создателя
// обычно предоставляют реализацию этого метода.
class Dialog is
    // Создатель также может предоставить некоторую реализацию
    // по умолчанию для фабричного метода.
    abstract method createButton():Button

    // Обратите внимание, что, несмотря на название, основная
    // ответственность создателя заключается не в создании продуктов.
    // Обычно он содержит какую-то базовую бизнес-логику,
    // основанную на объектах продуктов, возвращаемых фабричным методом.
    // Подклассы могут косвенно изменять эту бизнес-логику,
    // переопределив фабричный метод и возвращая из него
    // другой тип продукта.
    method render() is
        // Вызов фабричного метода для создания объекта продукта.
        Button okButton = createButton()
        // Теперь используем этот продукт.
        okButton.onClick(closeDialog)
        okButton.render()


// Конкретные создатели переопределяют фабричный метод,
// чтобы изменить тип получаемого продукта.
class WindowsDialog extends Dialog is
    method createButton():Button is
        return new WindowsButton()

class WebDialog extends Dialog is
    method createButton():Button is
        return new HTMLButton()


// Интерфейс продукта объявляет операции, которые все
// конкретные продукты должны реализовать.
interface Button is
    method render()
    method onClick(f)

// Конкретные продукты обеспечивают различные реализации
// интерфейса продукта.
class WindowsButton implements Button is
    method render(a, b) is
        // Отрисовываем кнопку в стиле Windows.
    method onClick(f) is
        // Привязываем нативное событие клика ОС.

class HTMLButton implements Button is
    method render(a, b) is
        // Возвращаем HTML-представление кнопки.
    method onClick(f) is
        // Привязываем событие клика в веб-браузере.


class Application is
    field dialog: Dialog

    // Приложение выбирает тип создателя в зависимости от
    // текущей конфигурации или настройки среды.
    method initialize() is
        config = readApplicationConfigFile()

        if (config.OS == "Windows") then
            dialog = new WindowsDialog()
        else if (config.OS == "Web") then
            dialog = new WebDialog()
        else
            throw new Exception("Error! Unknown operating system.")

    // Клиентский код работает с экземпляром конкретного
    // создателя, хотя и через его базовый интерфейс. Пока
    // клиент продолжает работать с создателем через базовый
    // интерфейс, вы можете передать ему любой подкласс создателя.
    method main() is
        this.initialize()
        dialog.render()

Применимость

Используйте фабричный метод, когда заранее неизвестны типы и зависимости объектов, с которыми должен работать ваш код.

Фабричный метод отделяет код создания продуктов от остального кода, который эти продукты использует.

Благодаря этому, код создания можно расширять, не трогая основной код. Так, чтобы добавить поддержку нового продукта, вам нужно создать новый подкласс создателя и определить в нём фабричный метод, возвращающий экземпляр нового продукта.

Используйте фабричный метод, когда хотите дать возможность пользователям вашего фреймворка или библиотеки расширять его внутренние компоненты.

Наследование, возможно, самый простой способ, чтобы расширить поведение по умолчанию библиотеки или фреймворка. Но как сделать так, чтобы фреймворк понимал, что вместо стандартного компонента нужно использовать ваш подкласс?

Решение состоит в том, чтобы сократить код, который создает компоненты в рамках фреймворка, до единственного фабричного метода и позволить пользователю переопределить этот метод в дополнение к расширению самого компонента.

Рассмотрим, как это будет работать. Представьте, что вы пишете приложение, используя фреймворк пользовательского интерфейса с открытым исходным кодом. В вашем приложении должны быть круглые кнопки, но во фреймворке есть только квадратные. Вы расширяете стандартный класс Button великолепным подклассом RoundButton. Но теперь вам нужно указать основному классу UIFramework использовать этот новый подкласс кнопки вместо подкласса по умолчанию.

Для этого вы создаете подкласс UIWithRoundButtons из базового класса фреймворка и переопределяете его метод createButton. Хотя этот метод в базовом классе возвращает объекты Button, вы заставляете свой подкласс возвращать объекты RoundButton. Теперь используйте класс UIWithRoundButtons вместо UIFramework. Вот и всё!

Используйте фабричный метод, когда хотите сэкономить системные ресурсы, повторно используя уже существующие объекты, вместо повторного создания их каждый раз.

Такая необходимость часто возникает при работе с большими ресурсоемкими объектами, такими как соединения с базами данных, файловые системы и сетевые ресурсы.

Давайте подумаем, что нужно сделать, чтобы повторно использовать существующий объект:

1. во-первых, вам нужно создать хранилище, чтобы отслеживать все созданные объекты;
2. когда кто-то запрашивает объект, программа должна поискать свободный объект внутри этого пула;
3. … а затем вернуть его клиентскому коду;
4. если свободных объектов нет, программа должна создать новый (и добавить его в пул).

Это много кода! И всё это должно быть собрано в одном месте, чтобы вы не засоряли программу дублированием кода.

Вероятно, наиболее очевидным и удобным местом, где можно было бы разместить этот код, является конструктор класса, объекты которого мы пытаемся повторно использовать. Однако конструктор по определению всегда должен возвращать новые объекты. Он не может возвращать существующие экземпляры.

Следовательно, вам нужен обычный метод, способный создавать новые объекты, а также повторно использовать существующие. Это очень похоже на фабричный метод.

Как реализовать

1. Сделайте так, чтобы все продукты следовали одному интерфейсу. Этот интерфейс должен объявлять методы, которые нужны в каждом продукте.

2. Добавьте в класс создателя пустой фабричный метод. Тип возвращаемого значения метода должен соответствовать общему интерфейсу продуктов.

3. В коде создателя найдите все ссылки на конструкторы продуктов. Один за другим замените их вызовами фабричного метода, извлекая код создания продукта в фабричный метод.

Возможно, вам потребуется добавить к фабричному методу временный параметр для управления типом возвращаемого продукта.

На этом этапе код фабричного метода может выглядеть довольно некрасиво. У него может быть большой оператор switch, который выбирает, какой класс продукта создать. Но не волнуйтесь, скоро мы это исправим.

4. Теперь создайте набор подклассов создателя для каждого типа продукта, указанного в фабричном методе. Переопределите фабричный метод в этих подклассах и извлеките соответствующие фрагменты кода создания продуктов из базового метода.

5. Если типов продуктов слишком много и нет смысла создавать подклассы для всех из них, вы можете повторно использовать в подклассах управляющий параметр из базового класса.

Например, представьте, что у вас есть следующая иерархия классов: базовый класс Mail (почта) с парой подклассов: AirMail (авиапочта) и GroundMail (наземная почта); класс Transport (транспорт) с подклассами Plane (самолет), Truck (грузовик) и Train (поезд). В то время как класс AirMail использует только объекты Plane, GroundMail может работать как с объектами Truck, так и с объектами Train. Вы можете создать новый подкласс (скажем, TrainMail) для обработки обоих случаев, но есть и другой вариант. Клиентский код может передать аргумент фабричному методу класса GroundMail, чтобы контролировать, какой продукт он хочет получить.

6. Если после всех этих извлечений базовый фабричный метод стал пустым, вы можете сделать его абстрактным. Если что-то осталось, вы можете сделать это поведением метода по умолчанию.

Достоинства и недостатки

Достоинства:

• Вы избегаете тесной связи между классом создателя и конкретными классами продуктов.
• Принцип единственной ответственности. Вы можете переместить код создания продукта в одно место в программе, что упростит поддержку кода.
• Принцип открытости/закрытости. Вы можете вводить в программу новые типы продуктов, не нарушая существующий клиентский код.

Недостатки:

• Код может стать более сложным, поскольку вам нужно ввести много новых подклассов для реализации шаблона. В идеале вы вводите этот паттерн в существующую иерархию классов-создателей.

Связи с другими паттернами

• Многие архитектуры начинаются с применения Фабричного метода (более простого и расширяемого через подклассы) и эволюционируют в сторону Абстрактной фабрики (Abstract Factory), Прототипа (Prototype) или Строителя (Builder) (более гибких, но и более сложных).
• Классы Абстрактной фабрики чаще всего реализуются с помощью Фабричного метода, хотя они могут быть построены и на основе Прототипа.
• Фабричный метод можно использовать вместе с Итератором (Iterator), чтобы подклассы коллекций могли создавать подходящие им итераторы.
• Прототип не опирается на наследование, поэтому у него нет ее недостатков. Но ему нужна сложная операция инициализации. Фабричный метод, наоборот, построен на наследовании, но не требует сложной инициализации.
• Фабричный метод можно рассматривать как частный случай Шаблонного метода (Template Method). Кроме того, Фабричный метод нередко бывает частью большого Шаблонного метода.

Примеры кода

Теги