- Суть паттерна
Строитель - это порождающий паттерн проектирования, который позволяет создавать сложные объекты пошагово. Строитель даёт возможность использовать один и тот же код строительства для получения разных представлений объектов.
- Проблема
Представьте сложный объект, требующий кропотливой пошаговой инициализации множества полей и вложенных объектов. Код инициализации таких объектов обычно спрятан внутри монструозного конструктора с десятком параметров. Либо ещё хуже - распылён по всему клиентскому коду.
Например, давайте подумаем о том, как создать объект Дом. Чтобы построить стандартный дом, нужно поставить 4 стены, установить двери, вставить пару окон и положить крышу. Но что, если вы хотите дом побольше да посветлее, имеющий сад, бассейн и прочее добро?
Самое простое решение - расширить класс Дом, создав подклассы для всех комбинаций параметров дома. Проблема такого подхода - это громадное количество классов, которые вам придётся создать. Каждый новый параметр, вроде цвета обоев или материала кровли, заставит вас создавать всё больше и больше классов для перечисления всех возможных вариантов.
Чтобы не плодить подклассы, вы можете подойти к решению с другой стороны. Вы можете создать гигантский конструктор Дома, принимающий уйму параметров для контроля над создаваемым продуктом. Действительно, это избавит вас от подклассов, но приведёт к другой проблеме.
Большая часть этих параметров будет простаивать, а вызовы конструктора будут выглядеть монструозно из-за длинного списка параметров. К примеру, далеко не каждый дом имеет бассейн, поэтому параметры, связанные с бассейнами, будут простаивать бесполезно в 99% случаев.
- Решение
Паттерн Строитель предлагает вынести конструирование объекта за пределы его собственного класса, поручив это дело отдельным объектам, называемым строителями.
Паттерн предлагает разбить процесс конструирования объекта на отдельные шаги (например, построитьСтены, вставитьДвери и другие). Чтобы создать объект, вам нужно поочерёдно вызывать методы строителя. Причём не нужно запускать все шаги, а только те, что нужны для производства объекта определённой конфигурации.
Зачастую один и тот же шаг строительства может отличаться для разных вариаций производимых объектов. Например, деревянный дом потребует строительства стен из дерева, а каменный - из камня.
В этом случае вы можете создать несколько классов строителей, выполняющих одни и те же шаги по-разному. Используя этих строителей в одном и том же строительном процессе, вы сможете получать на выходе различные объекты.
Например, один строитель делает стены из дерева и стекла, другой из камня и железа, третий из золота и бриллиантов. Вызвав одни и те же шаги строительства, в первом случае вы получите обычный жилой дом, во втором - маленькую крепость, а в третьем - роскошное жилище. Замечу, что код, который вызывает шаги строительства, должен работать со строителями через общий интерфейс, чтобы их можно было свободно взаимозаменять.
- Структура
- Шаги реализации
- Убедитесь в том, что создание разных представлений объекта можно свести к общим шагам.
- Опишите эти шаги в общем интерфейсе строителей.
- Для каждого из представлений объекта-продукта создайте по одному классу-строителю и реализуйте их методы строительства.
Не забудьте про метод получения результата. Обычно конкретные строители определяют собственные методы получения результата строительства. Вы не можете описать эти методы в интерфейсе строителей, поскольку продукты не обязательно должны иметь общий базовый класс или интерфейс. Но вы всегда сможете добавить метод получения результата в общий интерфейс, если ваши строители производят однородные продукты с общим предком. - Подумайте о создании класса директора. Его методы будут создавать различные конфигурации продуктов, вызывая разные шаги одного и того же строителя.
- Клиентский код должен будет создавать и объекты строителей, и объект директора. Перед началом строительства клиент должен связать определённого строителя с директором. Это можно сделать либо через конструктор, либо через сеттер, либо подав строителя напрямую в строительный метод директора.
- Результат строительства можно вернуть из директора, но только если метод возврата продукта удалось поместить в общий интерфейс строителей. Иначе вы жёстко привяжете директора к конкретным классам строителей.
- Преимущества
- Позволяет создавать продукты пошагово.
- Позволяет использовать один и тот же код для создания различных продуктов.
- Изолирует сложный код сборки продукта от его основной бизнес-логики.
- Недостатки
- Усложняет код программы из-за введения дополнительных классов.
- Клиент будет привязан к конкретным классам строителей, так как в интерфейсе директора может не быть метода получения результата.
Builder - это порождающий паттерн проектирования, который позволяет создавать объекты пошагово. В отличие от других порождающих паттернов, Строитель позволяет производить различные продукты, используя один и тот же процесс строительства.
Концептуальный пример
interface Builder
{
public function producePartA();
public function producePartB();
public function producePartC();
}
/**
* Классы Конкретного Строителя следуют интерфейсу Строителя и предоставляют
* конкретные реализации шагов построения. Ваша программа может иметь несколько
* вариантов Строителей, реализованных по-разному.
*/
class ConcreteBuilder1 implements Builder
{
private $product;
/**
* Новый экземпляр строителя должен содержать пустой объект продукта,
* который используется в дальнейшей сборке.
*/
public function __construct()
{
$this->reset();
}
public function reset()
{
$this->product = new Product1();
}
/**
* Все этапы производства работают с одним и тем же экземпляром продукта.
*/
public function producePartA()
{
$this->product->parts[] = "PartA1";
}
public function producePartB()
{
$this->product->parts[] = "PartB1";
}
public function producePartC()
{
$this->product->parts[] = "PartC1";
}
/**
* Конкретные Строители должны предоставить свои собственные методы
* получения результатов. Это связано с тем, что различные типы строителей
* могут создавать совершенно разные продукты с разными интерфейсами.
* Поэтому такие методы не могут быть объявлены в базовом интерфейсе
* Строителя (по крайней мере, в статически типизированном языке
* программирования). Обратите внимание, что PHP является динамически
* типизированным языком, и этот метод может быть в базовом интерфейсе.
* Однако мы не будем объявлять его здесь для ясности.
*
* Как правило, после возвращения конечного результата клиенту, экземпляр
* строителя должен быть готов к началу производства следующего продукта.
* Поэтому обычной практикой является вызов метода сброса в конце тела
* метода getProduct. Однако такое поведение не является обязательным, вы
* можете заставить своих строителей ждать явного запроса на сброс из кода
* клиента, прежде чем избавиться от предыдущего результата.
*/
public function getProduct()
{
$result = $this->product;
$this->reset();
return $result;
}
}
/**
* Имеет смысл использовать паттерн Строитель только тогда, когда ваши продукты
* достаточно сложны и требуют обширной конфигурации.
*
* В отличие от других порождающих паттернов, различные конкретные строители
* могут производить несвязанные продукты. Другими словами, результаты различных
* строителей могут не всегда следовать одному и тому же интерфейсу.
*/
class Product1
{
public $parts = [];
public function listParts()
{
echo "Product parts: " . implode(', ', $this->parts) . "\n\n";
}
}
/**
* Директор отвечает только за выполнение шагов построения в определённой
* последовательности. Это полезно при производстве продуктов в определённом
* порядке или особой конфигурации. Строго говоря, класс Директор необязателен,
* так как клиент может напрямую управлять строителями.
*/
class Director
{
/**
* @var Builder
*/
private $builder;
/**
* Директор работает с любым экземпляром строителя, который передаётся ему
* клиентским кодом. Таким образом, клиентский код может изменить конечный
* тип вновь собираемого продукта.
*/
public function setBuilder($builder)
{
$this->builder = $builder;
}
/**
* Директор может строить несколько вариаций продукта, используя одинаковые
* шаги построения.
*/
public function buildMinimalViableProduct()
{
$this->builder->producePartA();
}
public function buildFullFeaturedProduct()
{
$this->builder->producePartA();
$this->builder->producePartB();
$this->builder->producePartC();
}
}
/**
* Клиентский код создаёт объект-строитель, передаёт его директору, а затем
* инициирует процесс построения. Конечный результат извлекается из объекта-
* строителя.
*/
function clientCode($director)
{
$builder = new ConcreteBuilder1();
$director->setBuilder($builder);
echo "Standard basic product:\n";
$director->buildMinimalViableProduct();
$builder->getProduct()->listParts();
echo "Standard full featured product:\n";
$director->buildFullFeaturedProduct();
$builder->getProduct()->listParts();
// Помните, что паттерн Строитель можно использовать без класса Директор.
echo "Custom product:\n";
$builder->producePartA();
$builder->producePartC();
$builder->getProduct()->listParts();
}
$director = new Director();
clientCode($director);
Результат выполнения:
Standard basic product: Product parts: PartA1 Standard full featured product: Product parts: PartA1, PartB1, PartC1 Custom product: Product parts: PartA1, PartC1
Пример из реальной жизни
Одним из лучших применений паттерна Builder является конструктор запросов SQL. Интерфейс Строителя определяет общие шаги, необходимые для построения основного SQL-запроса. В тоже время Конкретные Строители, соответствующие различным диалектам SQL, реализуют эти шаги, возвращая части SQL-запросов, которые могут быть выполнены в данном движке базы данных.
/**
* Интерфейс Строителя объявляет набор методов для сборки SQL-запроса.
*
* Все шаги построения возвращают текущий объект строителя, чтобы обеспечить
* цепочку: $builder->select(...)->where(...)
*/
interface SQLQueryBuilder
{
public function select($table, $fields);
public function where($field, $value, $operator = '=');
public function limit($start, $offset);
// +100 других методов синтаксиса SQL...
public function getSQL();
}
/**
* Каждый Конкретный Строитель соответствует определённому диалекту SQL и может
* реализовать шаги построения немного иначе, чем остальные.
*
* Этот Конкретный Строитель может создавать SQL-запросы, совместимые с MySQL.
*/
class MysqlQueryBuilder implements SQLQueryBuilder
{
protected $query;
protected function reset()
{
$this->query = new \stdClass();
}
/**
* Построение базового запроса SELECT.
*/
public function select($table, $fields)
{
$this->reset();
$this->query->base = "SELECT " . implode(", ", $fields) . " FROM " . $table;
$this->query->type = 'select';
return $this;
}
/**
* Добавление условия WHERE.
*/
public function where($field, $value, $operator = '=')
{
if (!in_array($this->query->type, ['select', 'update', 'delete'])) {
throw new \Exception("WHERE can only be added to SELECT, UPDATE OR DELETE");
}
$this->query->where[] = "$field $operator '$value'";
return $this;
}
/**
* Добавление ограничения LIMIT.
*/
public function limit($start, $offset)
{
if (!in_array($this->query->type, ['select'])) {
throw new \Exception("LIMIT can only be added to SELECT");
}
$this->query->limit = " LIMIT " . $start . ", " . $offset;
return $this;
}
/**
* Получение окончательной строки запроса.
*/
public function getSQL()
{
$query = $this->query;
$sql = $query->base;
if (!empty($query->where)) {
$sql .= " WHERE " . implode(' AND ', $query->where);
}
if (isset($query->limit)) {
$sql .= $query->limit;
}
$sql .= ";";
return $sql;
}
}
/**
* Этот Конкретный Строитель совместим с PostgreSQL. Хотя Postgres очень похож
* на Mysql, в нем всё же есть ряд отличий. Чтобы повторно использовать общий
* код, мы расширяем его от строителя MySQL, переопределяя некоторые шаги
* построения.
*/
class PostgresQueryBuilder extends MysqlQueryBuilder
{
/**
* Помимо прочего, PostgreSQL имеет несколько иной синтаксис LIMIT.
*/
public function limit($start, $offset)
{
parent::limit($start, $offset);
$this->query->limit = " LIMIT " . $start . " OFFSET " . $offset;
return $this;
}
// + тонны других переопределений...
}
/**
* Обратите внимание, что клиентский код непосредственно использует объект
* строителя. Назначенный класс Директора в этом случае не нужен, потому что
* клиентский код практически всегда нуждается в различных запросах, поэтому
* последовательность шагов конструирования непросто повторно использовать.
*
* Поскольку все наши строители запросов создают продукты одного типа (это
* строка), мы можем взаимодействовать со всеми строителями, используя их общий
* интерфейс. Позднее, если мы реализуем новый класс Строителя, мы сможем
* передать его экземпляр существующему клиентскому коду, не нарушая его,
* благодаря интерфейсу SQLQueryBuilder.
*/
function clientCode($queryBuilder)
{
// ...
$query = $queryBuilder
->select("users", ["name", "email", "password"])
->where("age", 18, ">")
->where("age", 30, "<")
->limit(10, 20)
->getSQL();
echo $query;
// ...
}
/**
* Приложение выбирает подходящий тип строителя запроса в зависимости от текущей
* конфигурации или настроек среды.
*/
// if ($_ENV['database_type'] == 'postgres') {
// $builder = new PostgresQueryBuilder();
// } else {
// $builder = new MysqlQueryBuilder();
// }
//
// clientCode($builder);
echo "Testing MySQL query builder:\n";
clientCode(new MysqlQueryBuilder());
echo "\n\n";
echo "Testing PostgresSQL query builder:\n";
clientCode(new PostgresQueryBuilder());
Результат выполнения:
Testing MySQL query builder: SELECT name, email, password FROM users WHERE age > '18' AND age < '30' LIMIT 10, 20; Testing PostgresSQL query builder: SELECT name, email, password FROM users WHERE age > '18' AND age < '30' LIMIT 10 OFFSET 20;