Строитель(Builder)

Строитель(Builder)

KarmanovichDev

Первая часть - https://telegra.ph/StroitelBuilder-03-17


Продолжим с вопроса - Когда стоит применять паттерн?

  • У вас сложный процесс создания объекта, который можно/нужно разделить на шаги. Эти шаги не всегда строго обязательны(появляется управление снаружи процессом сборки)
  • Вы хотите создавать несколько представлений объекта при одинаковом алгоритме создания, но разности в частностях(реализация самих шагов)
  • Когда вы хотите чтобы процессом создания объекта можно было управлять снаружи, но доступ к создаваемому объекту был закрыт вплоть до момента создания.


Подытожим плюсы паттерна:

  •  Позволяет создавать сложные объекты пошагово(комбинируя шаги так, как нам нужно).
  •  Позволяет использовать один и тот же код для создания различных представлений одного и того же класса(отличаться будут состоянием).
  •  Инкапсулирует ВСЮ сложность сборки продукта от бизнес-логики.


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

  • Усложнение порога вхождения из-за появления новой сущности в коде, с которой нужно уметь работать(это не просто .run(), есть вариативность использования)


Вернёмся к схеме(UML):

Представим, что у нас есть сервис цен pricing. Он имеет открытый API для запросов на получение цен на услуги(продукты) компании.
Интерфейс его взаимодействия:

Абстрактный класс, для такого строителя может выглядеть так:

Тогда его реализация:

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

Ну и конечно использование:


И на финал я оставил такую вещь как "директор" для строителя:

Его задача инкапсулировать в себе алгоритм(последовательность) вызова строителя, чтобы оставлять бизнес логику чистой, и/или переиспользовать повторяющийся код:

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

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

Но что, если выбрать пиццу посложнее или захотеть переиспользовать этот код, чтобы не писать в нескольких местах один и тот же алгоритм действий? Правильно добавить директора!

Директор для строителя это ровно то что и в обычной жизни:

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

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

Вот как бы мог выглядеть директор для строителя пицц:

Обращаю внимание, что это не обязательно должен быть один директор с множеством методов. Точно так же это может быть несколько директоров с методом вроде .build()



Report Page