«Структурные паттерны». В этой группе собраны паттерны, которые позволяют менять структуру взаимодействия классов. «Адаптер» (Adapter) позволяет адаптировать интерфейс класса к конкретной ситуации, средствами шаблона «Мост» (Bridge) можно отделить интерфейс класса и его реализацию, «Компоновщик» (Composite) объединяет объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам единообразно обращаться к отдельным объектам и группам объектов. Паттерн «Оформитель» (Decorator, также известен как Wrapper, «Оболочка») позволяет динамически добавлять новое поведение к объекту, «Фасад» (Facade) – скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы. Шаблон «Приспособленец» (Flyweight) используется для облегчения работы с большим числом мелких объектов, а «Заместитель» (Proxy) – контролировать доступ к объекту, перехватывая все вызовы к нему.
В группе «Паттерны поведения» собраны шаблоны, ответственные за реализацию поведения объектов. «Цепочка ответов» (Chain of Response) позволяет пропустить запрос через цепочку объектов, «Команда» (Command) инкапсулирует команду в объект, «Интерпретатор» (Interpreter) позволяет создать общее декларативное решение для часто изменяющихся условий задачи. В шаблоне «Итератор» (Iterator) организуется последовательный доступ к коллекции, «Посредник» (Mediator) определяет упрощенный механизм взаимодействия классов, «Напоминание» (Memento) задает принципы, позволяющие записывать и восстанавливать внутреннее состояние объекта. Средствами шаблона «Наблюдатель» (Observer) можно оповещать об изменениях множества объектов, «Состояние» (State) – менять поведение объекта при изменении его состояния. «Стратегия» (Strategy) инкапсулирует алгоритм внутри класса.
Паттерн «Шаблонный метод» (Template Method) выделяет конкретные шаги в алгоритме и опирается на подклассы для их реализации. Средствами паттерна «Посетитель» (Visitor) в класс добавляются новые операции без его изменения.
В этой статье мы рассмотрим паттерны из первой группы – «Порождающие паттерны».
«Фабричный метод»
Паттерн Factory Method позволяет реализовать идею «виртуального конструктора», то есть создания объектов без явного указания их типа. Обычно он применяется, когда базовый класс делегирует потомкам право принятия решений о типе создаваемого объекта. Предположим, что нам надо написать программу для сохранения документа на диск, причем в разных форматах: XML, txt, doc и даже бинарном. Создадим базовый класс, где будет код открытия файла и фабричный метод для создания конкретного объекта, который будет сохранять данные в этот файл.
class DocumentWriter
{
public: virtual void writeDoc(const Document& doc, FILE& file) = 0;
};
class SaveDocument
{
protected:
virtual DocumentFileWriter* createDocumentWriter() const = 0;
public:
void save(const char* fileName)
{
FILE file = openFile(fileName);
// Фабричный метод
DocumentFileWriter* writer = createDocumentWriter();
writer->writeDoc();
closeFile(file);
}
};
Обратите внимание, что теперь не надо менять базовые классы для добавления любого нового формата выходного файла. Нужно только создать два простых дополнительных класса, например для вывода в XML (см. листинг 1).
Листинг 1
class DocumentWriterXml: public DocumentWriter
{
public:
virtual void writeDoc(const Document& doc, FILE& file)
{
// код для сохранения документа в формате XML в файл file
}
};
class SaveDocumentXml: public SaveDocument
{
protected:
virtual DocumentFileWriter* createDocumentWriter() const {return new DocumentWriterXml();}
};
Главный недостаток этого шаблона – необходимость создания двух дополнительных классов при добавлении новой функции.
«Абстрактная фабрика»
Шаблон Abstract Factory предоставляет интерфейс для создания семейств связанных или зависимых объектов, позволяя не указывать их конкретные классы. Обычно он применяется, когда нужно создавать составные объекты из конкретных частей (объектов). Классический пример – автомобиль. Если есть классы для разных частей автомобиля, то конкретный автомобиль будет состоять из множества таких частей, причем в каждой марке автомобиля будут конкретные части-детали. Для окончательной сборки автомобиля можно использовать «Абстрактную фабрику», классы-потомки которой будут создавать конкретные автомобили.
class AbstractCarFactory
{
public:
virtual Car* createCar() = 0;
virtual Engine* createEngine() = 0;
virtual Wheel* createWheel() = 0;
...
};
Нам также понадобятся иерархии классов для каждой из частей автомобиля (см. листинг 2).
Листинг 2
class Engine
{
public:
virtual void setSpeedLimit(int kmph);
virtual void addOil(float amount);
...
};
class Wheel
{
float mRadius;
public:
Wheel(float radius): mRadius(radius) {};
virtual float getRadius() const {return mRadius;}
...
};
class Car
{
public:
virtual const char* getName() const = 0;
virtual void setEngine(Engine* engine);
virtual void setWheels(Wheel* FR, Wheel* FL, Wheel* BR, Wheel* BL);
virtual void setFrontWheels(Wheel* FR, Wheel* FL);
virtual void setBackWheels(Wheel* BR, Wheel* BL);
...
};
Процедура сборки итогового объекта приводится в листинге 3.
Листинг 3
Car* createCar(AbstractCarFactory* carFactory)
{
Car* car = carFactory->createCar();
Engine* engine = carFactory->createEngine();
car->setEngine(engine);
car->setWheels(carFactory->createWheel(), carFactory->createWheel(), сarFactory->createWheel(), carFactory->createWheel());
// дальше может идти сколько угодно сложный код для «сборки» готового автомобиля из частей
return car;
}
Для добавления конкретных моделей автомобилей нужно просто создать новый класс, породив его от AbstractCarFactory. Задача этого класса – создать конкретные детали автомобиля. Понадобится также создать классы этих конкретных деталей, если их еще нет.
class BMW5CarFactory: public AbstractCarFactory
{
рublic:
virtual Car* createCar() {return new CarBMW5();}
virtual Engine* createEngine() {return new EngineBMW5();}
virtual Wheel* createWheel() {return new WheelNokian(16);}
...
};
class CarBMW5: public Car
{
public:
virtual const char* getName() const {return «BMW5»;}
...
};
Главный недостаток этого паттерна состоит в том, что со временем становится труднее вносить изменения в структуру классов. Например, если у нас уже имеется 100 конкретных моделей автомобилей, а мы решили добавить в AbstractCarFactory новую функцию, создающую фары, то нам придется изменить все 100 классов-потомков, создающих конкретные модели.