- 1. Причини
- 2. Проблеми
- 3. Структура
- 4. Приклад
- 5. Контрольний список
- 6. Емпіричні правила
Причини
- Відділення побудови складного об'єкта з його уявлення, щоб той самий процес побудови міг створювати різні уявлення.
- Розбирання складного уявлення, створення однієї мети з кількох варіацій.
Проблеми
Відділення алгоритму інтерпретації об'єкта (наприклад парсинг документа) від механізму збереження готового стану об'єкта. Наприклад, побудова з файлу 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 (гнучкіші, складніші), оскільки розробник виявляє, що потрібно більше гнучкості.
