Глава 3. Порождающие паттерны

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

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

Для порождающих паттернов актуальны две темы. Во-первых, эти паттерны инкапсулируют знания о конкретных классах, которые применяются в системе. Во-вторых, скрывают детали того, как эти классы создаются и стыкуются. Единственная информация об объектах, известная системе, – это их интерфейсы, определенные с помощью абстрактных классов. Следовательно, порождающие паттерны обеспечивают большую гибкость при решении вопроса о том, что создается, кто это создает, как и когда. Можно собрать систему из «готовых» объектов с самой различной структурой и функциональностью статически (на этапе компиляции) или динамически (во время выполнения).

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

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

Мы опустим детали того, что может встречаться в лабиринте и сколько игроков принимают участие в забаве, а сосредоточимся лишь на принципах создания лабиринта. Лабиринт мы определим как множество комнат. Любая комната «знает» о своих соседях, в качестве которых могут выступать другая комната, стена или дверь в другую комнату.

Классы Room (комната), Door (дверь) и Wall (стена) определяют компоненты лабиринта и используются во всех наших примерах. Мы определим только те части этих классов, которые важны для создания лабиринта. Не будем рассматривать игроков, операции отображения и блуждания в лабиринте и другие важные функции, не имеющие отношения к построению нашей структуры.

На диаграмме ниже показаны отношения между классами Room, Door и Wall.

У каждой комнаты есть четыре стороны. Для задания северной, южной, восточной и западной сторон будем использовать перечисление Direction в терминологии языка C++:

enum Direction {North, South, East, West};

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

Класс MapSite – это общий абстрактный класс для всех компонентов лабиринта. Определим в нем только одну операцию Enter. Когда вы входите в комнату, ваше местоположение изменяется. При попытке затем войти в дверь может произойти одно из двух. Если дверь открыта, то вы попадаете в следующую комнату. Если же дверь закрыта, то вы разбиваете себе нос:

class MapSite {

public:

virtual void Enter() = 0;

};

Операция Enter составляет основу для более сложных игровых операций. Например, если вы находитесь в комнате и говорите «Иду на восток», то игрой определяется, какой объект класса MapSite находится к востоку от вас, и для него вызывается операция Enter. Определенные в подклассах операции Enter «выяснят», изменили вы направление или расшибли нос. В реальной игре Enter могла бы принимать в качестве аргумента объект, представляющий блуждающего игрока.

Room – это конкретный подкласс класса MapSite, который определяет ключевые отношения между компонентами лабиринта. Он содержит ссылки на другие объекты MapSite, а также хранит номер комнаты. Номерами идентифицируются все комнаты в лабиринте:

class Room : public MapSite {

public:

Room(int roomNo);

MapSite* GetSide(Direction) const;

void SetSide(Direction, MapSite*);

virtual void Enter();

private:

MapSite* _sides[4];

int _roomNumber;

};

Следующие классы представляют стены и двери, находящиеся с каждой стороны комнаты:

class Wall : public MapSite {

public:

Wall();

virtual void Enter();

};

class Door : public MapSite {

public:

Door(Room* = 0, Room* = 0);

virtual void Enter();

Room* OtherSideFrom(Room*);

private:

Room* _room1;

Room* _room2;

bool _isOpen;

};

Но нам необходимо знать не только об отдельных частях лабиринта. Определим еще класс Maze для представления набора комнат. В этом классе есть операция RoomNo для нахождения комнаты по ее номеру:

class Maze {

public:

Maze();

void AddRoom(Room*);

Room* RoomNo(int) const;

private:

// ...

};

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

Определим также класс MazeGame, который создает лабиринт. Самый простой способ сделать это – строить лабиринт с помощью последовательности операций, добавляющих к нему компоненты, которые потом соединяются. Например, следующая функция-член создаст лабиринт из двух комнат с одной дверью между ними:

Maze* MazeGame::CreateMaze () {

Maze* aMaze = new Maze;

Room* r1 = new Room(1);

Room* r2 = new Room(2);

Door* theDoor = new Door(r1, r2);

aMaze->AddRoom(r1);

aMaze->AddRoom(r2);

r1->SetSide(North, new Wall);

r1->SetSide(East, theDoor);

r1->SetSide(South, new Wall);

r1->SetSide(West, new Wall);

r2->SetSide(North, new Wall);

r2->SetSide(East, new Wall);

r2->SetSide(South, new Wall);

r2->SetSide(West, theDoor);

return aMaze;

}

Довольно сложная функция, если принять во внимание, что она всего лишь создает лабиринт из двух комнат. Есть очевидные способы упростить ее. Например, конструктор класса Room мог бы инициализировать стороны без дверей заранее. Но это означает лишь перемещение кода в другое место. Суть проблемы не в размере этой функции-члена, а в ее негибкости. В функции жестко «зашита» структура лабиринта. Чтобы изменить структуру, придется изменить саму функцию, либо заместив ее (то есть полностью переписав заново), либо непосредственно модифицировав ее фрагменты. Оба пути чреваты ошибками и не способствуют повторному использованию.

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

Предположим, что мы хотим использовать уже существующую структуру
в новой игре с волшебными лабиринтами. В такой игре появляются не существовавшие ранее компоненты, например DoorNeedingSpell – запертая дверь, для открывания которой нужно произнести заклинание, или EnchantedRoom – комната, где есть необычные предметы, скажем, волшебные ключи или магические слова. Как легко изменить операцию CreateMaze, чтобы она создавала лабиринты с новыми классами объектов?

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

• если CreateMaze вызывает виртуальные функции вместо конструкторов для создания комнат, стен и дверей, то инстанцируемые классы можно подменить, создав подкласс MazeGame и переопределив в нем виртуальные функции. Такой подход применяется в паттерне фабричный метод;

• когда функции CreateMaze в качестве параметра передается объект, используемый для создания комнат, стен и дверей, то их классы можно изменить, передав другой параметр. Это пример паттерна абстрактная фабрика;

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

• если CreateMaze параметризована прототипами комнаты, двери и стены, которые она затем копирует и добавляет к лабиринту, то состав лабиринта можно варьировать, заменяя одни объекты-прототипы другими. Это паттерн прототип.

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

Паттерн Abstract Factory

Название и классификация паттерна

Абстрактная фабрика – паттерн, порождающий объекты.

Назначение

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

Известен также под именем

Kit (инструментарий).

Мотивация

Рассмотрим инструментальную программу для создания пользовательского интерфейса, поддерживающего разные стандарты внешнего облика, например Motif и Presentation Manager. Внешний облик определяет визуальное представление и поведение элементов пользовательского интерфейса («виджетов») – полос прокрутки, окон и кнопок. Чтобы приложение можно было перенести на другой стандарт, в нем не должен быть жестко закодирован внешний облик виджетов. Если инстанцирование классов для конкретного внешнего облика разбросано по всему приложению, то изменить облик впоследствии будет нелегко.

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

Для каждого стандарта внешнего облика существует определенный подкласс WidgetFactory. Каждый такой подкласс реализует операции, необходимые для со-здания соответствующего стандарту виджета. Например, операция CreateScrollBar в классе MotifWidgetFactory инстанцирует и возвращает полосу прокрутки
в стандарте Motif, тогда как соответствующая операция в классе PMWidgetFactory возвращает полосу прокрутки в стандарте Presentation Manager. Клиенты создают виджеты, пользуясь исключительно интерфейсом WidgetFactory, и им ничего не известно о классах, реализующих виджеты для конкретного стандарта. Другими словами, клиенты должны лишь придерживаться интерфейса, определенного абстрактным, а не конкретным классом.

Класс WidgetFactory также устанавливает зависимости между конкретными классами виджетов. Полоса прокрутки для Motif должна использоваться с кнопкой и текстовым полем Motif, и это ограничение поддерживается автоматически, как следствие использования класса MotifWidgetFactory.

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

Используйте паттерн абстрактная фабрика, когда:

• система не должна зависеть от того, как создаются, компонуются и представляются входящие в нее объекты;

• входящие в семейство взаимосвязанные объекты должны использоваться вместе и вам необходимо обеспечить выполнение этого ограничения;

• система должна конфигурироваться одним из семейств составляющих ее объектов;

• вы хотите предоставить библиотеку объектов, раскрывая только их интерфейсы, но не реализацию.

Структура

Участники

• AbstractFactory (WidgetFactory) – абстрактная фабрика:

– объявляет интерфейс для операций, создающих абстрактные объекты-продукты;

• ConcreteFactory (MotifWidgetFactory, PMWidgetFactory) – конкретная фабрика:

– реализует операции, создающие конкретные объекты-продукты;

• AbstractProduct (Window, ScrollBar) – абстрактный продукт:

– объявляет интерфейс для типа объекта-продукта;

• ConcreteProduct (MotifWindow, MotifScrollBar) – конкретный продукт:

– определяет объект-продукт, создаваемый соответствующей конкретной фабрикой;

– реализует интерфейс AbstractProduct;

• Client – клиент:

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

Отношения

• Обычно во время выполнения создается единственный экземпляр класса ConcreteFactory. Эта конкретная фабрика создает объекты-продукты, имеющие вполне определенную реализацию. Для создания других видов объектов клиент должен воспользоваться другой конкретной фабрикой;

• AbstractFactory передоверяет создание объектов-продуктов своему подклассу ConcreteFactory.

Результаты

Паттерн абстрактная фабрика обладает следующими плюсами и минусами:

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

• упрощает замену семейств продуктов. Класс конкретной фабрики появляется в приложении только один раз: при инстанцировании. Это облегчает замену используемой приложением конкретной фабрики. Приложение может изменить конфигурацию продуктов, просто подставив новую конкретную фабрику. Поскольку абстрактная фабрика создает все семейство продуктов, то и заменяется сразу все семейство. В нашем примере пользовательского интерфейса перейти от виджетов Motif к виджетам Presentation Manager можно, просто переключившись на продукты соответствующей фабрики
и заново создав интерфейс;

• гарантирует сочетаемость продуктов. Если продукты некоторого семейства спроектированы для совместного использования, то важно, чтобы приложение в каждый момент времени работало только с продуктами единственного семейства. Класс AbstractFactory позволяет легко соблюсти это ограничение;

• поддержать новый вид продуктов трудно. Расширение абстрактной фабрики для изготовления новых видов продуктов – непростая задача. Интерфейс AbstractFactory фиксирует набор продуктов, которые можно создать. Для поддержки новых продуктов необходимо расширить интерфейс фабрики, то есть изменить класс AbstractFactory и все его подклассы. Решение этой проблемы мы обсудим в разделе «Реализация».

Реализация

Вот некоторые полезные приемы реализации паттерна абстрактная фабрика:

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

• создание продуктов. Класс AbstractFactory объявляет только интерфейс для создания продуктов. Фактическое их создание – дело подклассов ConcreteProduct. Чаще всего для этой цели определяется фабричный метод для каждого продукта (см. паттерн фабричный метод). Конкретная фабрика специфицирует свои продукты путем замещения фабричного метода для каждого из них. Хотя такая реализация проста, она требует создавать новый подкласс конкретной фабрики для каждого семейства продуктов, даже если они почти ничем не отличаются.

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

Вот как можно реализовать фабрику на основе прототипов в языке Smalltalk. Конкретная фабрика хранит подлежащие клонированию прототипы
в словаре под названием partCatalog. Метод make: извлекает прототип и клонирует его:

make: partName

^ (partCatalog at: partName) copy

У конкретной фабрики есть метод для добавления деталей в каталог:

addPart: partTemplate named: partName

partCatalog at: partName put: partTemplate

Прототипы добавляются к фабрике путем идентификации их символом:

aFactory addPart: aPrototype named: #ACMEWidget

В языках, где сами классы являются настоящими объектами (например, Smalltalk и Objective C), возможны некие вариации подхода на базе прототипов. В таких языках класс можно представлять себе как вырожденный случай фабрики, умеющей создавать только один вид продуктов. Можно хранить классы внутри конкретной фабрики, которая создает разные конкретные продукты в переменных. Это очень похоже на прототипы. Такие классы создают новые экземпляры от имени конкретной фабрики. Новая фабрика инициализируется экземпляром конкретной фабрики с классами продуктов, а не путем порождения подкласса. Подобный подход задействует некоторые специфические свойства языка, тогда как подход, основанный на прототипах, от языка не зависит.

Как и для только что рассмотренной фабрики на базе прототипов в Smalltalk, в версии на основе классов будет единственная переменная экземпляра partCatalog, представляющая собой словарь, ключом которого является название детали. Но вместо хранения подлежащих клонированию прототипов partCatalog хранит классы продуктов. Метод make: выглядит теперь следующим образом:

make: partName

^ (partCatalog at: partName) new

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

Более гибкий, но не такой безопасный способ – добавить параметр к операциям, создающим объекты. Данный параметр определяет вид создаваемого объекта. Это может быть идентификатор класса, целое число, строка или что-то еще, однозначно описывающее вид продукта. При таком подходе классу AbstractFactory нужна только одна операция Make с параметром, указывающим тип создаваемого объекта. Данный прием применялся в обсуждавшихся выше абстрактных фабриках на основе прототипов и классов.

Такой вариант проще использовать в динамически типизированных языках вроде Smalltalk, нежели в статически типизированных, каким является C++. Воспользоваться им в C++ можно только, если у всех объектов имеется общий абстрактный базовый класс или если объекты-продукты могут быть безопасно приведены к корректному типу клиентом, который их запросил.
В разделе «Реализация» из описания паттерна фабричный метод показано, как реализовать такие параметризованные операции в C++.

Но даже если приведение типов не нужно, остается принципиальная проблема: все продукты возвращаются клиенту одним и тем же абстрактным интерфейсом с уже определенным типом возвращаемого значения. Клиент не может ни различить классы продуктов, ни сделать какие-нибудь предположения о них. Если клиенту нужно выполнить операцию, зависящую от подкласса, то она будет недоступна через абстрактный интерфейс. Хотя клиент мог бы выполнить динамическое приведение типа (например, с помощью оператора dynamic_cast в C++), это небезопасно и необязательно заканчивается успешно. Здесь мы имеем классический пример компромисса между высокой степенью гибкости и расширяемостью интерфейса.

Пример кода

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

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

class MazeFactory {

public:

MazeFactory();

virtual Maze* MakeMaze() const

{ return new Maze; }

virtual Wall* MakeWall() const

{ return new Wall; }

virtual Room* MakeRoom(int n) const

{ return new Room(n); }

virtual Door* MakeDoor(Room* r1, Room* r2) const

{ return new Door(r1, r2); }

};

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

Вот версия CreateMaze, в которой нет подобного недостатка, поскольку она принимает MazeFactory в качестве параметра:

Maze* MazeGame::CreateMaze (MazeFactory& factory) {

Maze* aMaze = factory.MakeMaze();

Room* r1 = factory.MakeRoom(1);

Room* r2 = factory.MakeRoom(2);

Door* aDoor = factory.MakeDoor(r1, r2);

aMaze->AddRoom(r1);

aMaze->AddRoom(r2);

r1->SetSide(North, factory.MakeWall());

r1->SetSide(East, aDoor);

r1->SetSide(South, factory.MakeWall());

r1->SetSide(West, factory.MakeWall());

r2->SetSide(North, factory.MakeWall());

r2->SetSide(East, factory.MakeWall());

r2->SetSide(South, factory.MakeWall());

r2->SetSide(West, aDoor);

return aMaze;

}

Мы можем создать фабрику EnchantedMazeFactory для производства волшебных лабиринтов, породив подкласс от MazeFactory. В этом подклассе замещены различные функции-члены, так что он возвращает другие подклассы классов Room, Wall и т.д.:

class EnchantedMazeFactory : public MazeFactory {

public:

EnchantedMazeFactory();

virtual Room* MakeRoom(int n) const

{ return new EnchantedRoom(n, CastSpell()); }

virtual Door* MakeDoor(Room* r1, Room* r2) const

{ return new DoorNeedingSpell(r1, r2); }

protected:

Spell* CastSpell() const;

};

А теперь предположим, что мы хотим построить для некоторой игры лабиринт, в одной из комнат которого заложена бомба. Если бомба взрывается, то она как минимум обрушивает стены. Тогда можно породить от класса Room подкласс, отслеживающий, есть ли в комнате бомба и взорвалась ли она. Также нам понадобится подкласс класса Wall, который хранит информацию о том, был ли нанесен ущерб стенам. Назовем эти классы соответственно RoomWithABomb
и BombedWall.

И наконец, мы определим класс BombedMazeFactory, являющийся подклассом BombedMazeFactory, который создает стены класса BombedWall
и комнаты класса RoomWithABomb. В этом классе надо переопределить всего две функции:

Wall* BombedMazeFactory::MakeWall () const {

return new BombedWall;

}

Room* BombedMazeFactory::MakeRoom(int n) const {

return new RoomWithABomb(n);

}

Для того чтобы построить простой лабиринт, в котором могут быть спрятаны бомбы, просто вызовем функцию CreateMaze, передав ей в качестве параметра BombedMazeFactory:

MazeGame game;

BombedMazeFactory factory;

game.CreateMaze(factory);

Для построения волшебных лабиринтов CreateMaze может принимать в качестве параметра и EnchantedMazeFactory.

Отметим, что MazeFactory – всего лишь набор фабричных методов. Это самый распространенный способ реализации паттерна абстрактная фабрика. Еще заметим, что MazeFactory – не абстрактный класс, то есть он работает
и как AbstractFactory, и как ConcreteFactory. Это еще одна типичная реализация для простых применений паттерна абстрактная фабрика. Поскольку MazeFactory – конкретный класс, состоящий только из фабричных методов, легко получить новую фабрику MazeFactory, породив подкласс и заместив в нем необходимые операции.

В функции CreateMaze используется операция SetSide для описания сторон комнат. Если она создает комнаты с помощью фабрики BombedMazeFactory, то лабиринт будет составлен из объектов класса RoomWithABomb, стороны которых описываются объектами класса BombedWall. Если классу RoomWithABomb потребуется доступ к членам BombedWall, не имеющим аналога в его предках, то придется привести ссылку на объекты-стены от типа Wall* к типу BombedWall*. Такое приведение к типу подкласса безопасно при условии, что аргумент действительно принадлежит классу BombedWall*, а это обязательно так, если стены создаются исключительно фабрикой BombedMazeFactory.

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

Рассмотрим версию MazeFactory на языке Smalltalk, в которой есть единственная операция make, принимающая вид изготавливаемого объекта в качестве параметра. Конкретная фабрика при этом будет хранить классы изготавливаемых объектов.

Для начала напишем на Smalltalk эквивалент CreateMaze:

createMaze: aFactory

| room1 room2 aDoor |

room1 := (aFactory make: #room) number: 1.

room2 := (aFactory make: #room) number: 2.

aDoor := (aFactory make: #door) from: room1 to: room2.

room1 atSide: #north put: (aFactory make: #wall).

room1 atSide: #east put: aDoor.

room1 atSide: #south put: (aFactory make: #wall).

room1 atSide: #west put: (aFactory make: #wall).

room2 atSide: #north put: (aFactory make: #wall).

room2 atSide: #east put: (aFactory make: #wall).

room2 atSide: #south put: (aFactory make: #wall).

room2 atSide: #west put: aDoor.

^ Maze new addRoom: room1; addRoom: room2; yourself

В разделе «Реализация» мы уже говорили о том, что классу MazeFactory нужна всего одна переменная экземпляра partCatalog, предоставляющая словарь, в котором ключом служит класс компонента. Напомним еще раз реализацию метода make:

make: partName

^ (partCatalog at: partName) new

Теперь мы можем создать фабрику MazeFactory и воспользоваться ей
для реализации createMaze. Данную фабрику мы создадим с помощью метода createMazeFactory класса MazeGame:

createMazeFactory

^ (MazeFactory new

addPart: Wall named: #wall;

addPart: Room named: #room;

addPart: Door named: #door;

yourself)

BombedMazeFactory и EnchantedMazeFactory создаются путем ассоциирования других классов с ключами. Например, EnchantedMazeFactory можно создать следующим образом:

createMazeFactory

^ (MazeFactory new

addPart: Wall named: #wall;

addPart: EnchantedRoom named: #room;

addPart: DoorNeedingSpell named: #door;

yourself)

Известные применения

В библиотеке InterViews [Lin92] для обозначения классов абстрактных фабрик используется суффикс «Kit». Так, для изготовления объектов пользовательского интерфейса с заданным внешним обликом определены абстрактные фабрики WidgetKit и DialogKit . В InterViews есть также класс LayoutKit, который генерирует разные объекты композиции в зависимости от того, какая требуется стратегия размещения. Например, размещение, которое концептуально можно было бы назвать «в строку», может потребовать разных объектов в зависимости от ориентации документа (книжной или альбомной).

В библиотеке ET++ [WGM88] паттерн абстрактная фабрика применяется для достижения переносимости между разными оконными системами (например, X Windows и SunView). Абстрактный базовый класс WindowSystem определяет интерфейс для создания объектов, которое представляют ресурсы оконной системы (MakeWindow, MakeFont, MakeColor и т.п.). Его конкретные подклассы реализуют эти интерфейсы для той или иной оконной системы. Во время выполнения ET++ создает экземпляр конкретного подкласса WindowSystem, который уже
и порождает объекты, соответствующие ресурсам данной оконной системы.

Родственные паттерны

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

Конкретная фабрика часто описывается паттерном одиночка.

Паттерн Builder

Название и классификация паттерна

Строитель – паттерн, порождающий объекты.

Назначение

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

Мотивация

Программа, в которую заложена возможность распознавания и чтения документа в формате RTF (Rich Text Format), должна также «уметь» преобразовывать его во многие другие форматы, например в простой ASCII-текст или в представление, которое можно отобразить в виджете для ввода текста. Однако число вероятных преобразований заранее неизвестно. Поэтому должна быть обеспечена возможность без труда добавлять новый конвертор.

Таким образом, нужно сконфигурировать класс RTFReader с помощью объекта TextConverter, который мог бы преобразовывать RTF в другой текстовый формат. При разборе документа в формате RTF класс RTFReader вызывает TextConverter для выполнения преобразования. Всякий раз, как RTFReader распознает лексему RTF (простой текст или управляющее слово), для ее преобразования объекту TextConverter посылается запрос. Объекты TextConverter отвечают как за преобразование данных, так и за представление лексемы в конкретном формате.

Подклассы TextConverter специализируются на различных преобразованиях и форматах. Например, ASCIIConverter игнорирует запросы на преобразование чего бы то ни было, кроме простого текста. С другой стороны, TeXConverter будет реализовывать все запросы для получения представления в формате редактора TЕX , собирая по ходу необходимую информацию о стилях. А TextWidgetConverter станет строить сложный объект пользовательского интерфейса, который позволит пользователю просматривать и редактировать текст.

Класс каждого конвертора принимает механизм создания и сборки сложного объекта и скрывает его за абстрактным интерфейсом. Конвертор отделен от загрузчика, который отвечает за синтаксический разбор RTF-документа.

В паттерне строитель абстрагированы все эти отношения. В нем любой класс конвертора называется строителем, а загрузчик – распорядителем. В применении к рассмотренному примеру строитель отделяет алгоритм интерпретации формата текста (то есть анализатор RTF-документов) от того, как создается и представляется документ в преобразованном формате. Это позволяет повторно использовать алгоритм разбора, реализованный в RTFReader, для создания разных текстовых представлений RTF-документов; достаточно передать в RTFReader различные подклассы класса TextConverter.

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

Используйте паттерн строитель, когда:

• алгоритм создания сложного объекта не должен зависеть от того, из каких частей состоит объект и как они стыкуются между собой;

• процесс конструирования должен обеспечивать различные представления конструируемого объекта.

Структура

Участники

• Builder (TextConverter) – строитель:

– задает абстрактный интерфейс для создания частей объекта Product;

• СoncreteBuilder (ASCIIConverter, TeXConverter, TextWidgetConverter) – конкретный строитель:

– конструирует и собирает вместе части продукта посредством реализации интерфейса Builder;

– определяет создаваемое представление и следит за ним;

– предоставляет интерфейс для доступа к продукту (например, GetASCIIText, GetTextWidget);

• Director (RTFReader) – распорядитель:

– конструирует объект, пользуясь интерфейсом Builder;

• Product (ASCIIText, TeXText, TextWidget) – продукт:

– представляет сложный конструируемый объект. ConcreteBuilder строит внутреннее представление продукта и определяет процесс его сборки;

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

Отношения

• клиент создает объект-распорядитель Director и конфигурирует его нужным объектом-строителем Builder;

• распорядитель уведомляет строителя о том, что нужно построить очередную часть продукта;

• строитель обрабатывает запросы распорядителя и добавляет новые части
к продукту;

• клиент забирает продукт у строителя.

Следующая диаграмма взаимодействий иллюстрирует взаимоотношения строителя и распорядителя с клиентом.

Результаты

Плюсы и минусы паттерна строитель и его применения:

• позволяет изменять внутреннее представление продукта. Объект Builder предоставляет распорядителю абстрактный интерфейс для конструирования продукта, за которым он может скрыть представление и внутреннюю структуру продукта, а также процесс его сборки. Поскольку продукт конструируется через абстрактный интерфейс, то для изменения внутреннего представления достаточно всего лишь определить новый вид строителя;

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

Каждый конкретный строитель ConcreteBuilder содержит весь код, необходимый для создания и сборки конкретного вида продукта. Код пишется только один раз, после чего разные распорядители могут использовать его повторно для построения вариантов продукта из одних и тех же частей. В примере с RTF-документом мы могли бы определить загрузчик для формата, отличного от RTF, скажем, SGMLReader, и воспользоваться теми же самыми классами TextConverters для генерирования представлений SGML-документов в виде ASCII-текста, TeX-текста или текстового виджета;

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

Реализация

Обычно существует абстрактный класс Builder, в котором определены операции для каждого компонента, который распорядитель может «попросить» создать. По умолчанию эти операции ничего не делают. Но в классе конкретного строителя ConcreteBuilder они замещены для тех компонентов, в создании которых он принимает участие.

Вот еще некоторые достойные внимания вопросы реализации:

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

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

Но иногда может потребоваться доступ к частям сконструированного к данному моменту продукта. В примере с лабиринтом, который будет описан
в разделе «Пример кода», интерфейс класса MazeBuilder позволяет добавлять дверь между уже существующими комнатами. Другим примером являются древовидные структуры, скажем, деревья синтаксического разбора, которые строятся снизу вверх. В этом случае строитель должен был бы вернуть узлы-потомки распорядителю, который затем передал бы их назад строителю, чтобы тот мог построить родительские узлы.

• почему нет абстрактного класса для продуктов. В типичном случае продукты, изготавливаемые различными строителями, имеют настолько разные представления, что изобретение для них общего родительского класса ничего не дает. В примере с RTF-документами трудно представить себе общий интерфейс у объектов ASCIIText и TextWidget, да он и не нужен. Поскольку клиент обычно конфигурирует распорядителя подходящим конкретным строителем, то, надо полагать, ему известно, какой именно подкласс класса Builder используется и как нужно обращаться с произведенными продуктами;

• пустые методы класса Builder по умолчанию. В C++ методы строителя намеренно не объявлены чисто виртуальными функциями-членами. Вместо этого они определены как пустые функции, что позволяет подклассу замещать только те операции, в которых он заинтересован.

Пример кода

Определим вариант функции-члена CreateMaze, которая принимает в качестве аргумента строитель, принадлежащий классу MazeBuilder.

Класс MazeBuilder определяет следующий интерфейс для построения лабиринтов:

class MazeBuilder {

public:

virtual void BuildMaze() { }

virtual void BuildRoom(int room) { }

virtual void BuildDoor(int roomFrom, int roomTo) { }

virtual Maze* GetMaze() { return 0; }

protected:

MazeBuilder();

};

Этот интерфейс позволяет создавать три вещи: лабиринт, комнату с конкретным номером, двери между пронумерованными комнатами. Операция GetMaze возвращает лабиринт клиенту. В подклассах MazeBuilder данная операция переопределяется для возврата реально созданного лабиринта.

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

Имея интерфейс MazeBuilder, можно изменить функцию-член CreateMaze, чтобы она принимала строитель в качестве параметра:

Maze* MazeGame::CreateMaze (MazeBuilder& builder) {

builder.BuildMaze();

builder.BuildRoom(1);

builder.BuildRoom(2);

builder.BuildDoor(1, 2);

return builder.GetMaze();

}

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

Как и другие порождающие паттерны, строитель инкапсулирует способ со-здания объектов; в данном случае с помощью интерфейса, определенного классом MazeBuilder. Это означает, что MazeBuilder можно повторно использовать для построения лабиринтов разных видов. В качестве примера приведем функцию CreateComplexMaze:

Maze* MazeGame::CreateComplexMaze (MazeBuilder& builder) {

builder.BuildRoom(1);

// ...

builder.BuildRoom(1001);

return builder.GetMaze();

}

Обратите внимание, что MazeBuilder не создает лабиринты самостоятельно, его основная цель – просто определить интерфейс для создания лабиринтов. Пустые реализации в этом интерфейсе определены только для удобства. Реальную работу выполняют подклассы MazeBuilder.

Подкласс StandardMazeBuilder содержит реализацию построения простых лабиринтов. Чтобы следить за процессом создания, используется переменная _currentMaze:

class StandardMazeBuilder : public MazeBuilder {

public:

StandardMazeBuilder();

virtual void BuildMaze();

virtual void BuildRoom(int);

virtual void BuildDoor(int, int);

virtual Maze* GetMaze();

private:

Direction CommonWall(Room*, Room*);

Maze* _currentMaze;

};

CommonWall (общая стена) – это вспомогательная операция, которая определяет направление общей для двух комнат стены.

Конструктор StandardMazeBuilder просто инициализирует _currentMaze:

StandardMazeBuilder::StandardMazeBuilder () {

_currentMaze = 0;

}

BuildMaze инстанцирует объект класса Maze, который будет собираться другими операциями и, в конце концов, возвратится клиенту (с помощью GetMaze):

void StandardMazeBuilder::BuildMaze () {

_currentMaze = new Maze;

}

Maze* StandardMazeBuilder::GetMaze () {

return _currentMaze;

}

Операция BuildRoom создает комнату и строит вокруг нее стены:

void StandardMazeBuilder::BuildRoom (int n) {

if (!_currentMaze->RoomNo(n)) {

Room* room = new Room(n);

_currentMaze->AddRoom(room);

room->SetSide(North, new Wall);

room->SetSide(South, new Wall);

room->SetSide(East, new Wall);

room->SetSide(West, new Wall);

}

Чтобы построить дверь между двумя комнатами, StandardMazeBuilder находит обе комнаты в лабиринте и их общую стену:

void StandardMazeBuilder::BuildDoor (int n1, int n2) {

Room* r1 = _currentMaze->RoomNo(n1);

Room* r2 = _currentMaze->RoomNo(n2);

Door* d = new Door(r1, r2);

r1->SetSide(CommonWall(r1,r2), d);

r2->SetSide(CommonWall(r2,r1), d);

}

Теперь для создания лабиринта клиенты могут использовать CreateMaze в сочетании с StandardMazeBuilder:

Maze* maze;

MazeGame game;

StandardMazeBuilder builder;

game.CreateMaze(builder);

maze = builder.GetMaze();

Мы могли бы поместить все операции класса StandardMazeBuilder в класс Maze и позволить каждому лабиринту строить самого себя. Но чем меньше класс Maze, тем проще он для понимания и модификации, а StandardMazeBuilder легко отделяется от Maze. Еще важнее то, что разделение этих двух классов позволяет иметь множество разновидностей класса MazeBuilder, в каждом из которых есть собственные классы для комнат, дверей и стен.

Необычным вариантом MazeBuilder является класс CountingMazeBuilder. Этот строитель вообще не создает никакого лабиринта, он лишь подсчитывает число компонентов разного вида, которые могли бы быть созданы:

class CountingMazeBuilder : public MazeBuilder {

public:

CountingMazeBuilder();

virtual void BuildMaze();

virtual void BuildRoom(int);

virtual void BuildDoor(int, int);

virtual void AddWall(int, Direction);

void GetCounts(int&, int&) const;

private:

int _doors;

int _rooms;

};

Конструктор инициализирует счетчики, а замещенные операции класса MazeBuilder увеличивают их:

CountingMazeBuilder::CountingMazeBuilder () {

_rooms = _doors = 0;

}

void CountingMazeBuilder::BuildRoom (int) {

_rooms++;

}

void CountingMazeBuilder::BuildDoor (int, int) {

_doors++;

}

void CountingMazeBuilder::GetCounts (

int& rooms, int& doors

) const {

rooms = _rooms;

doors = _doors;

}

Вот как клиент мог бы использовать класс CountingMazeBuilder:

int rooms, doors;

MazeGame game;

CountingMazeBuilder builder;

game.CreateMaze(builder);

builder.GetCounts(rooms, doors);

cout << "В лабиринте есть "

<< rooms << " комнат и "

<< doors << " дверей" << endl;

Известные применения

Приложение для конвертирования из формата RTF взято из библиотеки ET++ [WGM88]. В ней используется строитель для обработки текста, хранящегося в таком формате.

Паттерн строитель широко применяется в языке Smalltalk-80 [Par90]:

• класс Parser в подсистеме компиляции – это распорядитель, которому
в качестве аргумента передается объект ProgramNodeBuilder. Объект класса Parser извещает объект ProgramNodeBuilder после распознавания каждой ситаксической конструкции. После завершения синтаксического разбора Parser обращается к строителю за созданным деревом разбора и возвращает его клиенту;

• ClassBuilder – это строитель, которым пользуются все классы для создания своих подклассов. В данном случае этот класс выступает одновременно в качестве распорядителя и продукта;

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

Родственные паттерны

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

Паттерн компоновщик – это то, что часто создает строитель.

Паттерн Factory Method

Название и классификация паттерна

Фабричный метод – паттерн, порождающий классы.

Назначение

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

Известен также под именем

Virtual Constructor (виртуальный конструктор).

Мотивация

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

Рассмотрим каркас для приложений, способных представлять пользователю сразу несколько документов. Две основных абстракции в таком каркасе – это классы Application и Document. Оба класса абстрактные, поэтому клиенты должны порождать от них подклассы для создания специфичных для приложения реализаций. Например, чтобы создать приложение для рисования, мы определим классы DrawingApplication и DrawingDocument. Класс Application отвечает за управление документами и создает их по мере необходимости, допустим, когда пользователь выбирает из меню пункт Open (открыть) или New (создать).

Поскольку решение о том, какой подкласс класса Document инстанцировать, зависит от приложения, то Application не может «предсказать», что именно понадобится. Этому классу известно лишь, когда нужно инстанцировать новый документ, а не какой документ создать. Возникает дилемма: каркас должен инстанцировать классы, но «знает» он лишь об абстрактных классах, которые инстанцировать нельзя.

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

Подклассы класса Application переопределяют абстрактную операцию CreateDocument таким образом, чтобы она возвращала подходящий подкласс класса Document. Как только подкласс Application инстанцирован, он может инстанцировать специфические для приложения документы, ничего не зная об их классах. Операцию CreateDocument мы называем фабричным методом, поскольку она отвечает за «изготовление» объекта.

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

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

• классу заранее неизвестно, объекты каких классов ему нужно создавать;

• класс спроектирован так, чтобы объекты, которые он создает, специфицировались подклассами;

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

Структура

Участники

• Product (Document) – продукт:

– определяет интерфейс объектов, создаваемых фабричным методом;

• ConcreteProduct (MyDocument) – конкретный продукт:

– реализует интерфейс Product;

• Creator (Application) – создатель:

– объявляет фабричный метод, возвращающий объект типа Product. Creator может также определять реализацию по умолчанию фабричного метода, который возвращает объект ConcreteProduct;

– может вызывать фабричный метод для создания объекта Product.

• ConcreteCreator (MyApplication) – конкретный создатель:

– замещает фабричный метод, возвращающий объект СoncreteProduct.

Отношения

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

Результаты

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

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

А вот еще два последствия применения паттерна фабричный метод:

• предоставляет подклассам операции-зацепки (hooks). Создание объектов внутри класса с помощью фабричного метода всегда оказывается более гибким решением, чем непосредственное создание. Фабричный метод создает в подклассах операции-зацепки для предоставления расширенной версии объекта.

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

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

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

При таких ограничениях лучше использовать отдельный объект-манипулятор Manipulator, который реализует взаимодействие и контролирует его текущее состояние. У разных фигур будут разные манипуляторы, являющиеся подклассом Manipulator. Получающаяся иерархия класса Manipulator параллельна (по крайней мере, частично) иерархии класса Figure.

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

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

Реализация

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

• две основных разновидности паттерна. Во-первых, это случай, когда класс Creator является абстрактным и не содержит реализации объявленного
в нем фабричного метода. Вторая возможность: Creator – конкретный класс, в котором по умолчанию есть реализация фабричного метода. Редко, но встречается и абстрактный класс, имеющий реализацию по умолчанию;

В первом случае для определения реализации необходимы подклассы, поскольку никакого разумного умолчания не существует. При этом обходится проблема, связанная с необходимостью инстанцировать заранее неизвестные классы. Во втором случае конкретный класс Creator использует фабричный метод, главным образом ради повышения гибкости. Выполняется правило: «Создавай объекты в отдельной операции, чтобы подклассы могли подменить способ их создания». Соблюдение этого правила гарантирует, что авторы подклассов смогут при необходимости изменить класс объектов, инстанцируемых их родителем;

• параметризованные фабричные методы. Это еще один вариант паттерна, который позволяет фабричному методу создавать разные виды продуктов. Фабричному методу передается параметр, который идентифицирует вид создаваемого объекта. Все объекты, получающиеся с помощью фабричного метода, разделяют общий интерфейс Product. В примере с документами класс Application может поддерживать разные виды документов. Вы передаете методу CreateDocument лишний параметр, который и определяет, документ какого вида нужно создать.

В каркасе Unidraw для создания графических редакторов [VL90] используется именно этот подход для реконструкции объектов, сохраненных на диске. Unidraw определяет класс Creator с фабричным методом Create, которому в качестве аргумента передается идентификатор класса, определяющий, какой класс инстанцировать. Когда Unidraw сохраняет объект на диске, он сначала записывает идентификатор класса, а затем его переменные экземпляра. При реконструкции объекта сначала считывается идентификатор класса.

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

Параметризованный фабричный метод в общем случае имеет следующий вид (здесь MyProduct и YourProduct – подклассы Product):

class Creator {

public:

virtual Product* Create(ProductId);

};

Product* Creator::Create (ProductId id) {

if (id == MINE) return new MyProduct;

if (id == YOURS) return new YourProduct;

// выполнить для всех остальных продуктов...

return 0;

}

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

Например, подкласс MyCreator мог бы переставить местами MyProduct
и YourProduct для поддержки третьего подкласса TheirProduct:

Product* MyCreator::Create (ProductId id) {

if (id == YOURS) return new MyProduct;

if (id == MINE) return new YourProduct;

// N.B.: YOURS и MINE переставлены

if (id == THEIRS) return new TheirProduct;

return Creator::Create(id); // вызывается, если больше ничего

// не осталось

}

Обратите внимание, что в самом конце операция вызывает метод Create родительского класса. Так делается постольку, поскольку MyCreator::Create обрабатывает только продукты YOURS, MINE и THEIRS иначе, чем родительский класс. Поэтому MyCreator расширяет некоторые виды создаваемых продуктов, а создание остальных поручает своему родительскому классу;

• языково-зависимые вариации и проблемы. В разных языках возникают собственные интересные варианты и некоторые нюансы.

Так, в программах на Smalltalk часто используется метод, который возвращает класс подлежащего инстанцированию объекта. Фабричный метод Creator может воспользоваться возвращенным значением для создания продукта, а ConcreteCreator может сохранить или даже вычислить это значение. В результате привязка к типу конкретного инстанцируемого продукта ConcreteProduct происходит еще позже.

В версии примера Document на языке Smalltalk допустимо определить метод documentClass в классе Application. Данный метод возвращает подходящий класс Document для инстанцирования документов. Реализация метода documentClass в классе MyApplication возвращает класс MyDocument. Таким образом, в классе Application мы имеем

clientMethod

document := self documentClass new.

documentClass

self subclassResponsibility

а в классе MyApplication –

documentClass

^ MyDocument

что возвращает класс MyDocument, который должно инстанцировать приложение Application.

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

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

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

class Creator {

public:

Product* GetProduct();

protected:

virtual Product* CreateProduct();

private:

Product* _product;

};

Product* Creator::GetProduct () {

if (_product == 0) {

_product = CreateProduct();

}

return _product;

}

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

class Creator {

public:

virtual Product* CreateProduct() = 0;

};

template <class TheProduct>

class StandardCreator: public Creator {

public:

virtual Product* CreateProduct();

};

template <class TheProduct>

Product* StandardCreator<TheProduct>::CreateProduct () {

return new TheProduct;

}

С помощью данного шаблона клиент передает только класс продукта, порождать подклассы от Creator не требуется:

class MyProduct : public Product {

public:

MyProduct();

// ...

};

StandardCreator<MyProduct> myCreator;

• соглашения об именовании. На практике рекомендуется применять такие соглашения об именах, которые дают ясно понять, что вы пользуетесь фабричными методами. Например, каркас MacApp на платформе Macintosh [App89] всегда объявляет абстрактную операцию, которая определяет фабричный метод, в виде Class* DoMakeClass(), где Class – это класс продукта.

Пример кода

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

Сначала определим фабричные методы в игре MazeGame для создания объектов лабиринта, комнат, дверей и стен:

class MazeGame {

public:

Maze* CreateMaze();

// фабричные методы:

virtual Maze* MakeMaze() const

{ return new Maze; }

virtual Room* MakeRoom(int n) const

{ return new Room(n); }

virtual Wall* MakeWall() const

{ return new Wall; }

virtual Door* MakeDoor(Room* r1, Room* r2) const

{ return new Door(r1, r2); }

};

Каждый фабричный метод возвращает один из компонентов лабиринта. Класс MazeGame предоставляет реализации по умолчанию, которые возвращают простейшие варианты лабиринта, комнаты, двери и стены.

Теперь мы можем переписать функцию CreateMaze с использованием этих фабричных методов:

Maze* MazeGame::CreateMaze () {

Maze* aMaze = MakeMaze();

Room* r1 = MakeRoom(1);

Room* r2 = MakeRoom(2);

Door* theDoor = MakeDoor(r1, r2);

aMaze->AddRoom(r1);

aMaze->AddRoom(r2);

r1->SetSide(North, MakeWall());

r1->SetSide(East, theDoor);

r1->SetSide(South, MakeWall());

r1->SetSide(West, MakeWall());

r2->SetSide(North, MakeWall());

r2->SetSide(East, MakeWall());

r2->SetSide(South, MakeWall());

r2->SetSide(West, theDoor);

return aMaze;

}

В играх могут порождаться различные подклассы MazeGame для специализации частей лабиринта. В этих подклассах допустимо переопределение некоторых или всех методов, от которых зависят разновидности продуктов. Например, в игре BombedMazeGame продукты Room и Wall могут быть переопределены так, чтобы возвращать комнату и стену с заложенной бомбой:

class BombedMazeGame : public MazeGame {

public:

BombedMazeGame();

virtual Wall* MakeWall() const

{ return new BombedWall; }

virtual Room* MakeRoom(int n) const

{ return new RoomWithABomb(n); }

};

А в игре EnchantedMazeGame допустимо определить такие варианты:

class EnchantedMazeGame : public MazeGame {

public:

EnchantedMazeGame();

virtual Room* MakeRoom(int n) const

{ return new EnchantedRoom(n, CastSpell()); }

virtual Door* MakeDoor(Room* r1, Room* r2) const

{ return new DoorNeedingSpell(r1, r2); }

protected:

Spell* CastSpell() const;

};

Известные применения

Фабричные методы в изобилии встречаются в инструментальных библиотеках и каркасах. Рассмотренный выше пример с документами – это типичное применение в каркасе MacApp и библиотеке ET++ [WGM88]. Пример с манипулятором заимствован из каркаса Unidraw.

Класс View в схеме модель/вид/контроллер из языка Smalltalk-80 имеет метод defaultController, который создает контроллер, и этот метод выглядит как фабричный [Par90]. Но подклассы View специфицируют класс своего контроллера по умолчанию, определяя метод defaultControllerClass, возвращающий класс, экземпляры которого создает defaultController. Таким образом, реальным фабричным методом является defaultControllerClass, то есть метод, который должен переопределяться в подклассах.

Более необычным является пример фабричного метода parserClass, тоже взятый из Smalltalk-80, который определяется поведением Behavior (суперкласс всех объектов, представляющих классы). Он позволяет классу использовать специализированный анализатор своего исходного кода. Например, клиент может определить класс SQLParser для анализа исходного кода класса, содержащего встроенные предложения на языке SQL. Класс Behavior реализует parserClass так, что тот возвращает стандартный для Smalltalk класс анализатора Parser. Класс же, включающий предложения SQL, замещает этот метод (как метод класса) и во-звращает класс SQLParser.

Система Orbix ORB от компании IONA Technologies [ION94] использует фабричный метод для генерирования подходящих заместителей (см. паттерн заместитель) в случае, когда объект запрашивает ссылку на удаленный объект. Фабричный метод позволяет без труда заменить подразумеваемого заместителя, например таким, который применяет кэширование на стороне клиента.

Родственные паттерны

Абстрактная фабрика часто реализуется с помощью фабричных методов. Пример в разделе «Мотивация» из описания абстрактной фабрики иллюстрирует также и паттерн фабричные методы.

Паттерн фабричные методы часто вызывается внутри шаблонных методов. В примере с документами NewDocument – это шаблонный метод.

Прототипы не нуждаются в порождении подклассов от класса Creator. Однако им часто бывает необходима операция Initialize в классе Product. Creator использует Initialize для инициализации объекта. Фабричному методу такая операция не требуется.

Паттерн Prototype

Название и классификация паттерна

Прототип – паттерн, порождающий объекты.

Назначение

Задает виды создаваемых объектов с помощью экземпляра-прототипа и создает новые объекты путем копирования этого прототипа.

Мотивация

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

Предположим, что каркас предоставляет абстрактный класс Graphic для графических компонентов вроде нот и нотных станов, а также абстрактный класс Tool для определения инструментов в палитре. Кроме того, в каркасе имеется предопределенный подкласс GraphicTool для инструментов, которые создают графические объекты и добавляют их в документ.

Однако класс GraphicTool создает некую проблему для проектировщика каркаса. Классы нот и нотных станов специфичны для нашего приложения,
а класс GraphicTool принадлежит каркасу. Этому классу ничего неизвестно о том, как создавать экземпляры наших музыкальных классов и добавлять их в партитуру. Можно было бы породить от GraphicTool подклассы для каждого вида музыкальных объектов, но тогда оказалось бы слишком много классов, отличающихся только тем, какой музыкальный объект они инстанцируют. Мы знаем, что гибкой альтернативой порождению подклассов является композиция. Вопрос в том, как каркас мог бы воспользоваться ею для параметризации экземпляров GraphicTool классом того объекта Graphic, который предполагается создать.

Решение – заставить GraphicTool создавать новый графический объект, копируя или «клонируя» экземпляр подкласса класса Graphic. Этот экземпляр мы будем называть прототипом. GraphicTool параметризуется прототипом, который он должен клонировать и добавить в документ. Если все подклассы Graphic поддерживают операцию Clone, то GraphicTool может клонировать любой вид графических объектов.

Итак, в нашем музыкальном редакторе каждый инструмент для создания музыкального объекта – это экземпляр класса GraphicTool, инициализированный тем или иным прототипом. Любой экземпляр GraphicTool будет создавать музыкальный объект, клонируя его прототип и добавляя клон в партитуру.

Можно воспользоваться паттерном прототип, чтобы еще больше сократить число классов. Для целых и половинных нот у нас есть отдельные классы, но, быть может, это излишне. Вместо этого они могли бы быть экземплярами одного и того же класса, инициализированного разными растровыми изображениями и длительностями звучания. Инструмент для создания целых нот становится просто объектом класса GraphicTool, в котором прототип MusicalNote инициализирован целой нотой. Это может значительно уменьшить число классов в системе. Заодно упрощается добавление нового вида нот в музыкальный редактор.

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

Используйте паттерн прототип, когда система не должна зависеть от того, как в ней создаются, компонуются и представляются продукты:

• инстанцируемые классы определяются во время выполнения, например
с помощью динамической загрузки;

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

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

Структура

Участники

• Prototype (Graphic) – прототип:

– объявляет интерфейс для клонирования самого себя;

• ConcretePrototype (Staff – нотный стан, WholeNote – целая нота, HalfNote – половинная нота) – конкретный прототип:

– реализует операцию клонирования себя;

• Client (GraphicTool) – клиент:

– создает новый объект, обращаясь к прототипу с запросом клонировать себя.

Отношения

Клиент обращается к прототипу, чтобы тот создал свою копию.

Результаты

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

Ниже перечислены дополнительные преимущества паттерна прототип:

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

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

Такой дизайн позволяет пользователям определять новые классы без программирования. Фактически клонирование объекта аналогично инстанцированию класса. Паттерн прототип может резко уменьшить число необходимых системе классов. В нашем музыкальном редакторе с помощью одного только класса GraphicTool удастся создать бесконечное разнообразие музыкальных объектов;

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

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

• уменьшение числа подклассов. Паттерн фабричный метод часто порождает иерархию классов Creator, параллельную иерархии классов продуктов. Прототип позволяет клонировать прототип, а не запрашивать фабричный метод создать новый объект. Поэтому иерархия класса Creator становится вообще ненужной. Это преимущество касается главным образом языков типа C++, где классы не рассматриваются как настоящие объекты. В языках же типа Smalltalk и Objective C это не так существенно, поскольку всегда можно использовать объект-класс в качестве создателя. В таких языках объекты-классы уже выступают как прототипы;

• динамическое конфигурирование приложения классами. Некоторые среды позволяют динамически загружать классы в приложение во время его выполнения. Паттерн прототип – это ключ к применению таких возможностей
в языке типа C++.

Приложение, которое создает экземпляры динамически загружаемого класса, не может обращаться к его конструктору статически. Вместо этого исполняющая среда автоматически создает экземпляр каждого класса в момент его загрузки и регистрирует экземпляр в диспетчере прототипов (см. раздел «Реализация»). Затем приложение может запросить у диспетчера прототипов экземпляры вновь загруженных классов, которые изначально не были связаны с программой. Каркас приложений ET++ [WGM88] в своей исполняющей среде использует именно такую схему.

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

Реализация

Прототип особенно полезен в статически типизированных языках вроде C++, где классы не являются объектами, а во время выполнения информации о типе недостаточно или нет вовсе. Меньший интерес данный паттерн представляет для таких языков, как Smalltalk или Objective C, в которых и так уже есть нечто эквивалентное прототипу (именно – объект-класс) для создания экземпляров каждого класса. В языки, основанные на прототипах, например Self [US87], где создание любого объекта выполняется путем клонирования прототипа, этот паттерн просто встроен.

Рассмотрим основные вопросы, возникающие при реализации прототипов:

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

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

• реализация операции Clone. Самая трудная часть паттерна прототип – правильная реализация операции Clone. Особенно сложно это в случае, когда в структуре объекта есть круговые ссылки.

В большинстве языков имеется некоторая поддержка для клонирования объектов. Например, Smalltalk предоставляет реализацию копирования, которую все подклассы наследуют от класса Object. В C++ есть копирующий конструктор. Но эти средства не решают проблему «глубокого и поверхностного копирования» [GR83]. Суть ее в следующем: должны ли при клонировании объекта клонироваться также и его переменные экземпляра или клон просто разделяет с оригиналом эти переменные?

Поверхностное копирование просто, и часто его бывает достаточно. Именно такую возможность и предоставляет по умолчанию Smalltalk. В C++ копирующий конструктор по умолчанию выполняет почленное копирование, то есть указатели разделяются копией и оригиналом. Но для клонирования прототипов со сложной структурой обычно необходимо глубокое копирование, поскольку клон должен быть независим от оригинала. Поэтому нужно гарантировать, что компоненты клона являются клонами компонентов прототипа. При клонировании вам приходится решать, что именно может разделяться и может ли вообще.

Если объекты в системе предоставляют операции Save (сохранить) и Load (загрузить), то разрешается воспользоваться ими для реализации операции Clone по умолчанию, просто сохранив и сразу же загрузив объект. Операция Save сохраняет объект в буфере памяти, а Load создает дубликат, реконструируя объект из буфера;

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

Может оказаться, что в ваших классах прототипов уже определяются операции для установки и очистки некоторых важных элементов состояния. Если так, то этими операциями можно воспользоваться сразу после клонирования. В противном случае, возможно, понадобится ввести операцию Initialize (см. раздел «Пример кода»), которая принимает начальные значения в качестве аргументов и соответственно устанавливает внутреннее состояние клона. Будьте осторожны, если операция Clone реализует глубокое копирование: копии может понадобиться удалять (явно или внутри Initialize) перед повторной инициализацией.

Пример кода

Мы определим подкласс MazePrototypeFactory класса MazeFactory. Этот подкласс будет инициализироваться прототипами объектов, которые ему предстоит создавать, поэтому нам не придется порождать подклассы только ради изменения классов создаваемых стен или комнат.

MazePrototypeFactory дополняет интерфейс MazeFactory конструктором, принимающим в качестве аргументов прототипы:

class MazePrototypeFactory : public MazeFactory {

public:

MazePrototypeFactory(Maze*, Wall*, Room*, Door*);

virtual Maze* MakeMaze() const;

virtual Room* MakeRoom(int) const;

virtual Wall* MakeWall() const;

virtual Door* MakeDoor(Room*, Room*) const;

private:

Maze* _prototypeMaze;

Room* _prototypeRoom;

Wall* _prototypeWall;

Door* _prototypeDoor;

};

Новый конструктор просто инициализирует свои прототипы:

MazePrototypeFactory::MazePrototypeFactory (

Maze* m, Wall* w, Room* r, Door* d

) {

_prototypeMaze = m;

_prototypeWall = w;

_prototypeRoom = r;

_prototypeDoor = d;

}

Функции-члены для создания стен, комнат и дверей похожи друг на друга: каждая клонирует, а затем инициализирует прототип. Вот определения функций MakeWall и MakeDoor:

Wall* MazePrototypeFactory::MakeWall () const {

return _prototypeWall->Clone();

}

Door* MazePrototypeFactory::MakeDoor (Room* r1, Room *r2) const {

Door* door = _prototypeDoor->Clone();

door->Initialize(r1, r2);

return door;

}

Мы можем применить MazePrototypeFactory для создания прототипичного или принимаемого по умолчанию лабиринта, просто инициализируя его прототипами базовых компонентов:

MazeGame game;

MazePrototypeFactory simpleMazeFactory(

new Maze, new Wall, new Room, new Door

);

Maze* maze = game.CreateMaze(simpleMazeFactory);

Для изменения типа лабиринта инициализируем MazePrototypeFactory другим набором прототипов. Следующий вызов создает лабиринт с дверью типа BombedDoor и комнатой типа RoomWithABomb:

MazePrototypeFactory bombedMazeFactory(

new Maze, new BombedWall,

new RoomWithABomb, new Door

);

Объект, который предполагается использовать в качестве прототипа, например экземпляр класса Wall, должен поддерживать операцию Clone. Кроме того, у него должен быть копирующий конструктор для клонирования. Также может потребоваться операция для повторной инициализации внутреннего состояния. Мы добавим в класс Door операцию Initialize, чтобы дать клиентам возможность инициализировать комнаты клона.

Сравните следующее определение Door с приведенным на стр. 91:

class Door : public MapSite {

public:

Door();

Door(const Door&);

virtual void Initialize(Room*, Room*);

virtual Door* Clone() const;

virtual void Enter();

Room* OtherSideFrom(Room*);

private:

Room* _room1;

Room* _room2;

};

Door::Door (const Door& other) {

_room1 = other._room1;

_room2 = other._room2;

}

void Door::Initialize (Room* r1, Room* r2) {

_room1 = r1;

_room2 = r2;

}

Door* Door::Clone () const {

return new Door(*this);

}

Подкласс BombedWall должен заместить операцию Clone и реализовать соответствующий копирующий конструктор:

class BombedWall : public Wall {

public:

BombedWall();

BombedWall(const BombedWall&);

virtual Wall* Clone() const;

bool HasBomb();

private:

bool _bomb;

};

BombedWall::BombedWall (const BombedWall& other) : Wall(other) {

_bomb = other._bomb;

}

Wall* BombedWall::Clone () const {

return new BombedWall(*this);

}

Операция BombedWall::Clone возвращает Wall*, а ее реализация – указатель на новый экземпляр подкласса, то есть BombedWall*. Мы определяем Clone в базовом классе именно таким образом, чтобы клиентам, клонирующим прототип, не надо было знать о его конкретных подклассах. Клиентам никогда не придется приводить значение, возвращаемое Clone, к нужному типу.

В Smalltalk разрешается использовать стандартный метод копирования, унаследованный от класса Object, для клонирования любого прототипа MapSite. Можно воспользоваться фабрикой MazeFactory для изготовления любых необходимых прототипов. Например, допустимо создать комнату по ее номеру #room. В классе MazeFactory есть словарь, сопоставляющий именам прототипы. Его метод make: выглядит так:

make: partName

^ (partCatalog at: partName) copy

Имея подходящие методы для инициализации MazeFactory прототипами, можно было бы создать простой лабиринт с помощью следующего кода:

CreateMaze

on: (MazeFactory new

with: Door new named: #door;

with: Wall new named: #wall;

with: Room new named: #room;

yourself)

где определение метода класса on: для CreateMaze имеет вид

on: aFactory

| room1 room2 |

room1 := (aFactory make: #room) location: 1@1.

room2 := (aFactory make: #room) location: 2@1.

door := (aFactory make: #door) from: room1 to: room2.

room1

atSide: #north put: (aFactory make: #wall);

atSide: #east put: door;

atSide: #south put: (aFactory make: #wall);

atSide: #west put: (aFactory make: #wall).

room2

atSide: #north put: (aFactory make: #wall);

atSide: #east put: (aFactory make: #wall);

atSide: #south put: (aFactory make: #wall);

atSide: #west put: door.

^ Maze new

addRoom: room1;

addRoom: room2;

yourself

Известные применения

Быть может, впервые паттерн прототип был использован в системе Sketchpad Ивана Сазерленда (Ivan Sutherland) [Sut63]. Первым широко известным применением этого паттерна в объектно-ориентированном языке была система ThingLab, в которой пользователи могли сформировать составной объект, а затем превратить его в прототип, поместив в библиотеку повторно используемых объектов [Bor81]. Адель Голдберг и Давид Робсон упоминают прототипы в качестве паттернов в работе [GR83], но Джеймс Коплиен [Cop92] рассматривает этот вопрос гораздо шире. Он описывает связанные с прототипом идиомы языка C++ и приводит много примеров и вариантов.

Etgdb – это оболочка отладчиков на базе ET++, где имеется интерфейс вида point-and-click (укажи и щелкни) для различных командных отладчиков. Для каждого из них есть свой подкласс DebuggerAdaptor. Например, GdbAdaptor настраивает etgdb на синтаксис команд GNU gdb, а SunDbxAdaptor – на отладчик dbx компании Sun. Набор подклассов DebuggerAdaptor не «зашит» в etgdb. Вместо этого он получает имя адаптера из переменной среды, ищет в глобальной таблице прототип с указанным именем, а затем его клонирует. Добавить к etgdb новые отладчики можно, связав ядро с подклассом DebuggerAdaptor, разработанным для этого отладчика.

Библиотека приемов взаимодействия в программе Mode Composer хранит прототипы объектов, поддерживающих различные способы интерактивных отношений [Sha90]. Любой созданный с помощью Mode Composer способ взаимодействия можно применить в качестве прототипа, если поместить его в библиотеку. Паттерн прототип позволяет программе поддерживать неограниченное число вариантов отношений.

Пример музыкального редактора, обсуждавшийся в начале этого раздела, основан на каркасе графических редакторов Unidraw [VL90].

Родственные паттерны

В некоторых отношениях прототип и абстрактная фабрика являются конкурентами. Но их используют и совместно. Абстрактная фабрика может хранить набор прототипов, которые клонируются и возвращают изготовленные объекты.

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

Паттерн Singleton

Название и классификация паттерна

Одиночка – паттерн, порождающий объекты.

Назначение

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

Мотивация

Для некоторых классов важно, чтобы существовал только один экземпляр. Хотя в системе может быть много принтеров, но возможен лишь один спулер. Должны быть только одна файловая система и единственный оконный менеджер. В цифровом фильтре может находиться только один аналого-цифровой преобразователь (АЦП). Бухгалтерская система обслуживает только одну компанию.

Как гарантировать, что у класса есть единственный экземпляр и что этот экземпляр легко доступен? Глобальная переменная дает доступ к объекту, но не запрещает инстанцировать класс в нескольких экземплярах.

Более удачное решение – сам класс контролирует то, что у него есть только один экземпляр, может запретить создание дополнительных экземпляров, перехватывая запросы на создание новых объектов, и он же способен предоставить доступ к своему экземпляру. Это и есть назначение паттерна одиночка.

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

Используйте паттерн одиночка, когда:

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

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

Структура

Участники

• Singleton – одиночка:

– определяет операцию Instance, которая позволяет клиентам получать доступ к единственному экземпляру. Instance – это операция класса, то есть метод класса в терминологии Smalltalk и статическая функция-член в C++;

– может нести ответственность за создание собственного уникального экземпляра.

Отношения

Клиенты получают доступ к экземпляру класса Singleton только через его операцию Instance.

Результаты

У паттерна одиночка есть определенные достоинства:

• контролируемый доступ к единственному экземпляру. Поскольку класс Singleton инкапсулирует свой единственный экземпляр, он полностью контролирует то, как и когда клиенты получают доступ к нему;

• уменьшение числа имен. Паттерн одиночка – шаг вперед по сравнению с глобальными переменными. Он позволяет избежать засорения пространства имен глобальными переменными, в которых хранятся уникальные экземпляры;

• допускает уточнение операций и представления. От класса Singleton можно порождать подклассы, а приложение легко сконфигурировать экземпляром расширенного класса. Можно конкретизировать приложение экземпляром того класса, который необходим во время выполнения;

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

• большая гибкость, чем у операций класса. Еще один способ реализовать функциональность одиночки – использовать операции класса, то есть статические функции-члены в C++ и методы класса в Smalltalk. Но оба этих приема препятствуют изменению дизайна, если потребуется разрешить наличие нескольких экземпляров класса. Кроме того, статические функции-члены в C++ не могут быть виртуальными, так что их нельзя полиморфно заместить в подклассах.

Реализация

При использовании паттерна одиночка надо рассмотреть следующие вопросы:

• гарантирование единственного экземпляра. Паттерн одиночка устроен так, что тот единственный экземпляр, который имеется у класса, – самый обычный, но больше одного экземпляра создать не удастся. Чаще всего для этого прячут операцию, создающую экземпляры, за операцией класса (то есть за статической функцией-членом или методом класса), которая гарантирует создание не более одного экземпляра. Данная операция имеет доступ к переменной, где хранится уникальный экземпляр, и гарантирует инициализацию переменной этим экземпляром перед возвратом ее клиенту. При таком подходе можно не сомневаться, что одиночка будет создан и инициализирован перед первым использованием.

В C++ операция класса определяется с помощью статической функции-члена Instance класса Singleton. В этом классе есть также статическая переменная-член _instance, которая содержит указатель на уникальный экземпляр.

Класс Singleton объявлен следующим образом:

class Singleton {

public:

static Singleton* Instance();

protected:

Singleton();

private:

static Singleton* _instance;

};

А реализация такова:

Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance () {

if (_instance == 0) {

_instance = new Singleton;

}

return _instance;

}

Клиенты осуществляют доступ к одиночке исключительно через функцию-член Instance. Переменная _instance инициализируется нулем, а статическая функция-член Instance возвращает ее значение, инициализируя ее уникальным экземпляром, если в текущий момент оно равно 0. Функция Instance использует отложенную инициализацию: возвращаемое ей значение не создается и не хранится вплоть до момента первого обращения.

Обратите внимание, что конструктор защищенный. Клиент, который попытается инстанцировать класс Singleton непосредственно, получит ошибку на этапе компиляции. Это дает гарантию, что будет создан только один экземпляр.

Далее, поскольку _instance – указатель на объект класса Singleton, то функция-член Instance может присвоить этой переменной указатель на любой подкласс данного класса. Применение возможности мы увидим
в разделе «Пример кода».

О реализации в C++ скажем особо. Недостаточно определить рассматриваемый патерн как глобальный или статический объект, а затем полагаться на автоматическую инициализацию. Тому есть три причины:

– мы не можем гарантировать, что будет объявлен только один экземпляр статического объекта;

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

– в С++ не определяется порядок вызова конструкторов для глобальных объектов через границы единиц трансляции [ES90]. Это означает, что между одиночками не может существовать никаких зависимостей. Если они есть, то ошибок не избежать.

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

В Smalltalk функция, возвращающая уникальный экземпляр, реализуется как метод класса Singleton. Чтобы гарантировать единственность экземпляра, следует заместить операцию new. Получающийся класс мог бы иметь два метода класса (в них SoleInstance – это переменная класса, которая больше нигде не используется):

new

self error: ‘не удается создать новый объект’

default

SoleInstance isNil ifTrue: [SoleInstance := super new].

^ SoleInstance

• порождение подклассов Singleton. Основной вопрос не столько в том, как определить подкласс, а в том, как сделать, чтобы клиенты могли использовать его единственный экземпляр. По существу, переменная, ссылающаяся на экземпляр одиночки, должна инициализироваться вместе с экземпляром подкласса. Простейший способ добиться этого – определить одиночку, которого нужно применять в операции Instance класса Singleton. В разделе «Пример кода» показывается, как можно реализовать эту технику с помощью переменных среды.

Другой способ выбора подкласса Singleton – вынести реализацию операции Instance из родительского класса (например, MazeFactory) и поместить ее в подкласс. Это позволит программисту на C++ задать класс одиночки на этапе компоновки (скомпоновав программу с объектным файлом, содержащим другую реализацию), но от клиента одиночка будет по-прежнему скрыт.

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

Ее можно добиться за счет использования реестра одиночек. Вместо того чтобы задавать множество возможных классов Singleton в операции Instance, одиночки могут регистрировать себя по имени в некотором всем известном реестре.

Реестр сопоставляет одиночкам строковые имена. Когда операции Instance нужен некоторый одиночка, она запрашивает его у реестра по имени. Начинается поиск указанного одиночки, и, если он существует, реестр возвращает его. Такой подход освобождает Instance от необходимости «знать» все возможные классы или экземпляры Singleton. Нужен лишь единый для всех классов Singleton интерфейс, включающий операции с реестром:

class Singleton {

public:

static void Register(const char* name, Singleton*);

static Singleton* Instance();

protected:

static Singleton* Lookup(const char* name);

private:

static Singleton* _instance;

static List<NameSingletonPair>* _registry;

};

Операция Register регистрирует экземпляр класса Singleton под указанным именем. Чтобы не усложнять реестр, мы будем хранить в нем список объектов NameSingletonPair. Каждый такой объект отображает имя на одиночку. Операция Lookup ищет одиночку по имени. Предположим, что имя нужного одиночки передается в переменной среды:

Singleton* Singleton::Instance () {

if (_instance == 0) {

const char* singletonName = getenv("SINGLETON");

// пользователь или среда предоставляют это имя на стадии

// запуска программы

_instance = Lookup(singletonName);

// Lookup возвращает 0, если такой одиночка не найден

}

return _instance;

}

В какой момент классы Singleton регистрируют себя? Одна из возможностей – конструктор. Например, подкласс MySingleton мог бы работать так:

MySingleton::MySingleton() {

// ...

Singleton::Register("MySingleton", this);

}

Разумеется, конструктор не будет вызван, пока кто-то не инстанцирует класс, но ведь это та самая проблема, которую паттерн одиночка и пытается разрешить! В C++ ее можно попытаться обойти, определив статический экземпляр класса MySingleton. Например, можно вставить строку

static MySingleton theSingleton;

в файл, где находится реализация MySingleton.

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

Пример кода

Предположим, нам надо определить класс MazeFactory для создания лабиринтов, описанный на стр. 99. MazeFactory определяет интерфейс для построения различных частей лабиринта. В подклассах эти операции могут переопределяться, чтобы возвращать экземпляры специализированных классов продуктов, например объекты BombedWall, а не просто Wall.

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

Для простоты предположим, что мы никогда не порождаем подклассов от MazeFactory. (Чуть ниже будет рассмотрен альтернативный подход.) В C++ для того, чтобы превратить фабрику в одиночку, мы добавляем в класс MazeFactory статическую операцию Instance и статический член _instance, в котором будет храниться единственный экземпляр. Нужно также сделать конструктор защищенным, чтобы предотвратить случайное инстанцирование, в результате которого будет создан лишний экземпляр:

class MazeFactory {

public:

static MazeFactory* Instance();

// здесь находится существующий интерфейс

protected:

MazeFactory();

private:

static MazeFactory* _instance;

};

Реализация класса такова:

MazeFactory* MazeFactory::_instance = 0;

MazeFactory* MazeFactory::Instance () {

if (_instance == 0) {

_instance = new MazeFactory;

}

return _instance;

}

Теперь посмотрим, что случится, когда у MazeFactory есть подклассы и определяется, какой из них использовать. Вид лабиринта мы будем выбирать с помощью переменной среды, поэтому добавим код, который инстанцирует нужный подкласс MazeFactory в зависимости от значения данной переменной. Лучше всего поместить код в операцию Instance, поскольку она уже и так инстанцирует MazeFactory:

MazeFactory* MazeFactory::Instance () {

if (_instance == 0) {

const char* mazeStyle = getenv("MAZESTYLE");

if (strcmp(mazeStyle, "bombed") == 0) {

_instance = new BombedMazeFactory;

} else if (strcmp(mazeStyle, "enchanted") == 0) {

_instance = new EnchantedMazeFactory;

// ... другие возможные подклассы

} else { // по умолчанию

_instance = new MazeFactory;

}

return _instance;

}

Отметим, что операцию Instance нужно модифицировать при определении каждого нового подкласса MazeFactory. В данном приложении это, может быть, и не проблема, но для абстрактных фабрик, определенных в каркасе, такой подход трудно назвать приемлемым.

Одно из решений – воспользоваться принципом реестра, описанным в разделе «Реализация». Может помочь и динамическое связывание, тогда приложению не нужно будет загружать все неиспользуемые подклассы.

Известные применения

Примером паттерна одиночка в Smalltalk-80 [Par90] является множество изменений кода, представленное классом ChangeSet. Более тонкий пример – это отношение между классами и их метаклассами. Метаклассом называется класс класса, каждый метакласс существует в единственном экземпляре. У метакласса нет имени (разве что косвенное, определяемое экземпляром), но он контролирует свой уникальный экземпляр, и создать второй обычно не разрешается.

В библиотеке InterViews для создания пользовательских интерфейсов [LCI+92] – паттерн одиночка применяется для доступа к единственным экземплярам классов Session (сессия) и WidgetKit (набор виджетов). Классом Session определяется главный цикл распределения событий в приложении. Он хранит пользовательские настройки стиля и управляет подключением к одному или нескольким физическим дисплеям. WidgetKit – это абстрактная фабрика для определения внешнего облика интерфейсных виджетов. Операция WidgetKit::instance() определяет конкретный инстанцируемый подкласс WidgetKit на основе переменной среды, которую устанавливает Session. Аналогичная операция в классе Session «выясняет», поддерживаются ли монохромные или цветные дисплеи, и соответственно конфигурирует одиночку Session.

Родственные паттерны

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

Обсуждение порождающих паттернов

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

Другой способ параметризации системы в большей степени основан на композиции объектов. Вы определяете объект, которому известно о классах объектов-продуктов, и делаете его параметром системы. Это ключевой аспект таких паттернов, как абстрактная фабрика, строитель и прототип. Для всех трех
характерно создание «фабричного объекта», который изготавливает продукты.
В абстрактной фабрике фабричный объект производит объекты разных классов. Фабричный объект строителя постепенно создает сложный продукт, следуя специальному протоколу. Фабричный объект прототипа изготавливает продукт путем копирования объекта-прототипа. В последнем случае фабричный объект
и прототип – это одно и то же, поскольку именно прототип отвечает за возврат продукта.

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

• применить паттерн фабричный метод. Тогда для каждого подкласса класса Graphic в палитре будет создан свой подкласс GraphicTool. В классе GraphicTool будет присутствовать операция NewGraphic, переопределяемая каждым подклассом;

• использовать паттерн абстрактная фабрика. Возникнет иерархия классов GraphicsFactories, по одной для каждого подкласса Graphic. В этом случае каждая фабрика создает только один продукт: CircleFactory – окружности Circle, LineFactory – отрезки Line и т.д. GraphicTool параметризуется фабрикой для создания подходящих графических объектов;

• применить паттерн прототип. Тогда в каждом подклассе Graphic будет реализована операция Clone, а GraphicTool параметризуется прототипом создаваемого графического объекта.

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

Абстрактная фабрика лишь немногим лучше, поскольку требует создания равновеликой иерархии классов GraphicsFactory. Абстрактную фабрику следует предпочесть фабричному методу лишь тогда, когда уже и так существует иерархия класса GraphicsFactory: либо потому, что ее автоматически строит компилятор (как в Smalltalk или Objective C), либо она необходима для другой части системы.

Очевидно, целям каркаса графических редакторов лучше всего отвечает паттерн прототип, поскольку для его применения требуется лишь реализовать операцию Clone в каждом классе Graphics. Это сокращает число подклассов,
а Clone можно с пользой применить и для решения других задач – например, для реализации пункта меню Duplicate (дублировать), – а не только для инстанцирования.

В случае применения паттерна фабричный метод проект в большей степени поддается настройке и оказывается лишь немногим более сложным. Другие паттерны нуждаются в создании новых классов, а фабричный метод – только в со-здании одной новой операции. Часто этот паттерн рассматривается как стандартный способ создания объектов, но вряд ли его стоит рекомендовать в ситуации, когда инстанцируемый класс никогда не изменяется или когда инстанцирование выполняется внутри операции, которую легко можно заместить в подклассах (например, во время инициализации).

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