Генеративті дизайн үлгілері - құрылысшы

Builder, шаблоны проектирования, Строитель

Причины

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

Проблематика

Отделение алгоритма интерпретации объекта (например, парсинг документа) от механизма сохранения готового состояния объекта. Например построение из файла RTF более сложного или иного целевого объекта, как ASCII текст, TeX, текстовый виджет. Основное внимание уделяется созданию сложных агрегатов.

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

Обеспечивает более тонкий контроль над процессом строительства объекта. В отличие от шаблонов создания, которые строят продукты за один вызов, шаблон Builder последовательно создает продукт под контролем «Директора».

Структура

Reader инкапсулирует разбор информации на входе. А Builder позволяет полиморфное создание множества своеобразных представлений или целей.

Пример

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

Контрольный список

• Решите, является ли задаче проблемой с общим входом для данных и множеством возможных представлений (или выходов).
• Инкапсулируйте синтаксический анализ общего входа в классе Reader.
• Создайте стандартный протокол для создания всех возможных выходных представлений. Захватите шаги этого протокола в интерфейсе Builder.
• Определите производный класс Builder для каждого целевого представления.
• Клиент создает объект Reader и объект Builder и регистрирует последний с первым.
• Клиент просит Reader «построить».
• Клиент просит Builder вернуть результат.

Эмпирические правила

• Иногда шаблоны создания дополняют друг друга: Builder может использовать один из других шаблонов для реализации компонентов, которые будут созданы. Abstract Factory, Builder и Prototype могут использовать Singleton в своих реализациях.
• Builder фокусируется на построении сложного объекта шаг за шагом. Абстрактная фабрика подчеркивает семейство объектов (простых или сложных). Builder возвращает продукт в качестве последнего шага, но, что касается абстрактной фабрики, продукт немедленно возвращается.
• Builder часто создает Composite.
• Часто проекты начинаются с использования Factory Method (менее сложные, настраиваемые, подклассы размножаются) и развиваются в направлении Abstract Factory, Prototype или Builder (более гибкие, более сложные), поскольку разработчик обнаруживает, что требуется больше гибкости.