Достоинства и недостатки
Достоинства:
Скрывает сам процесс порождения объектов, а также делает систему независимой от типов создаваемых объектов, специфичных для различных семейств или групп (пользователи оперируют этими объектами через соответствующие абстрактные интерфейсы);
Позволяет быстро настраивать систему на нужное семейство создаваемых объектов. В случае многоплатформенного графического приложения для перехода на новую платформу, то есть для замены графических элементов (кнопок, меню, полос прокрутки) одного стиля другим достаточно создать нужный подкласс абстрактной фабрики. При этом условие невозможности одновременного использования элементов разных стилей для некоторой платформы будет выполнено автоматически.
Недостатки:
Трудно добавлять новые типы создаваемых объектов или заменять существующие, так как интерфейс базового класса абстрактной фабрики фиксирован. Например, если для текущего примера нужно будет ввести новый вид военной единицы - осадные орудия, то необходимо будет добавить новый фабричный метод, объявив его интерфейс в полиморфном базовом классе AbstractFactory и реализовав во всех подклассах. Снять это ограничение можно следующим образом. Все создаваемые объекты должны наследовать от общего абстрактного базового класса, а в единственный фабричный метод в качестве параметра необходимо передавать идентификатор типа объекта, который нужно создать. Однако в этом случае необходимо учитывать следующий момент. Фабричный метод создает объект запрошенного подкласса, но при этом возвращает его с интерфейсом общего абстрактного класса в виде ссылки или указателя, поэтому для такого объекта будет затруднительно выполнить какую-либо операцию, специфичную для подкласса.
Шаблон «Строитель»
Шаблон «Строитель» (Builder) позволяет не только создавать объекты, но и конструировать сложные объекты по заложенному в него алгоритму.
Может помочь в решении следующих задач:
В системе могут существовать сложные объекты, создание которых за одну операцию затруднительно или невозможно. Требуется поэтапное построение объектов с контролем результатов выполнения каждого этапа.
Данные должны иметь несколько представлений. Приведем классический пример. Пусть есть некоторый исходный документ в формате RTF (Rich Text Format), в общем случае содержащий текст, графические изображения и служебную информацию о форматировании (размер и тип шрифтов, отступы и др.). Если этот документ в формате RTF преобразовать в другие форматы (например, Microsoft Word или простой ASCII-текст), то полученные документы и будут представлениями исходных данных.
Шаблон «Строитель» определяет алгоритм поэтапного создания продукта в специальном классе Director (распорядитель), а ответственность за координацию процесса сборки отдельных частей продукта возлагает на иерархию классов. В этой иерархии базовый класс объявляет интерфейсы для построения отдельных частей продукта, а соответствующие подклассы их реализуют подходящим образом, например, создают или получают нужные ресурсы, сохраняют промежуточные результаты, контролируют результаты выполнения операций.
Рисунок 8 Диаграмма классов для шаблона «Строитель»
Класс Director содержит указатель или ссылку на экземпляр одного из дочерних классов Builder, определяющего соответствующе представление. После этого, класс Director может обрабатывать клиентские запросы на создание объекта. Получив такой запрос, с помощью имеющегося экземпляра строителя, Director строит продукт по частям, а затем возвращает его пользователю.
Исходный код:
public abstract class Builder
{
protected abstract Product BuildPart();
public Product GetProduct()
{
return BuildPart();
}
}
public class ConcreteBuilder : Builder
{
protected override Product BuildPart()
{
Product product = new Product();
BuildPart1();
BuildPart2();
return product;
}
private void BuildPart1()
{
}
private void BuildPart2()
{
}
}
public class Director
{
Builder _builder;
public Product Construct()
{
return _builder.GetProduct();
}
}
public class Product
{
}