- Суть паттерна
Цепочка обязанностей - это поведенческий паттерн проектирования, который позволяет передавать запросы последовательно по цепочке обработчиков. Каждый последующий обработчик решает, может ли он обработать запрос сам и стоит ли передавать запрос дальше по цепи.
- Проблема
Представьте, что вы делаете систему приёма онлайн-заказов. Вы хотите ограничить к ней доступ так, чтобы только авторизованные пользователи могли создавать заказы. Кроме того, определённые пользователи, владеющие правами администратора, должны иметь полный доступ к заказам.
Вы быстро сообразили, что эти проверки нужно выполнять последовательно. Ведь пользователя можно попытаться залогинить в систему, если его запрос содержит логин и пароль. Но если такая попытка не удалась, то проверять расширенные права доступа попросту не имеет смысла.
На протяжении следующих нескольких месяцев вам пришлось добавить ещё несколько таких последовательных проверок.
- Кто-то резонно заметил, что неплохо бы проверять данные, передаваемые в запросе перед тем, как вносить их в систему - вдруг запрос содержит данные о покупке несуществующих продуктов.
- Кто-то предложил блокировать массовые отправки формы с одним и тем же логином, чтобы предотвратить подбор паролей ботами.
- Кто-то заметил, что форму заказа неплохо бы доставать из кеша, если она уже была однажды показана.
С каждой новой фичей код проверок, выглядящий как большой клубок условных операторов, всё больше и больше раздувался. При изменении одного правила приходилось трогать код всех проверок. А для того, чтобы применить проверки к другим ресурсам, пришлось продублировать их код в других классах.
Поддерживать такой код стало не только очень хлопотно, но и затратно. И вот в один прекрасный день вы получаете задачу рефакторинга...
- Решение
Как и многие другие поведенческие паттерны, Цепочка обязанностей базируется на том, чтобы превратить отдельные поведения в объекты. В нашем случае каждая проверка переедет в отдельный класс с единственным методом выполнения. Данные запроса, над которым происходит проверка, будут передаваться в метод как аргументы.
А теперь по-настоящему важный этап. Паттерн предлагает связать объекты обработчиков в одну цепь. Каждый из них будет иметь ссылку на следующий обработчик в цепи. Таким образом, при получении запроса обработчик сможет не только сам что-то с ним сделать, но и передать обработку следующему объекту в цепочке. Передавая запросы в первый обработчик цепочки, вы можете быть уверены, что все объекты в цепи смогут его обработать. При этом длина цепочки не имеет никакого значения.
И последний штрих. Обработчик не обязательно должен передавать запрос дальше, причём эта особенность может быть использована по-разному. В примере с фильтрацией доступа обработчики прерывают дальнейшие проверки, если текущая проверка не прошла. Ведь нет смысла тратить попусту ресурсы, если и так понятно, что с запросом что-то не так.
- Структура
- Шаги реализации
1. Создайте интерфейс обработчика и опишите в нём основной метод обработки.
Продумайте, в каком виде клиент должен передавать данные запроса в обработчик. Самый гибкий способ - превратить данные запроса в объект и передавать его целиком через параметры метода обработчика.
2. Имеет смысл создать абстрактный базовый класс обработчиков, чтобы не дублировать реализацию метода получения следующего обработчика во всех конкретных обработчиках.
Добавьте в базовый обработчик поле для хранения ссылки на следующий объект цепочки. Устанавливайте начальное значение этого поля через конструктор. Это сделает объекты обработчиков неизменяемыми. Но если программа предполагает динамическую перестройку цепочек, можете добавить и сеттер для поля.
Реализуйте базовый метод обработки так, чтобы он перенаправлял запрос следующему объекту, проверив его наличие. Это позволит полностью скрыть поле-ссылку от подклассов, дав им возможность передавать запросы дальше по цепи, обращаясь к родительской реализации метода.
3. Один за другим создайте классы конкретных обработчиков и реализуйте в них методы обработки запросов. При получении запроса каждый обработчик должен решить:
- Может ли он обработать запрос или нет?
- Следует ли передать запрос следующему обработчику или нет?
4. Клиент может собирать цепочку обработчиков самостоятельно, опираясь на свою бизнес-логику, либо получать уже готовые цепочки извне. В последнем случае цепочки собираются фабричными объектами, опираясь на конфигурацию приложения или параметры окружения.
5. Клиент может посылать запросы любому обработчику в цепи, а не только первому. Запрос будет передаваться по цепочке до тех пор, пока какой-то обработчик не откажется передавать его дальше, либо когда будет достигнут конец цепи.
6. Клиент должен знать о динамической природе цепочки и быть готов к таким случаям:
- Цепочка может состоять из единственного объекта.
- Запросы могут не достигать конца цепи.
- Запросы могут достигать конца, оставаясь необработанными.
- Преимущества
- Уменьшает зависимость между клиентом и обработчиками.
- Реализует принцип единственной обязанности.
- Реализует принцип открытости/закрытости.
- Недостатки
- Запрос может остаться никем не обработанным.
Chain of Responsibility - это поведенческий паттерн, позволяющий передавать запрос по цепочке потенциальных обработчиков, пока один из них не обработает запрос. Избавляет от жёсткой привязки отправителя запроса к его получателю, позволяя выстраивать цепь из различных обработчиков динамически.
Концептуальный пример
/**
* Интерфейс Обработчика объявляет метод построения цепочки обработчиков.
* Он также объявляет метод для выполнения запроса.
*/
interface Handler
{
public function setNext($handler);
public function handle($request);
}
/**
* Поведение цепочки по умолчанию может быть реализовано внутри базового класса обработчика.
*/
abstract class AbstractHandler implements Handler
{
/**
* @var Handler
*/
private $nextHandler;
public function setNext($handler)
{
$this->nextHandler = $handler;
// Возврат обработчика отсюда позволит связать обработчики простым
// способом, вот так:
// $monkey->setNext($squirrel)->setNext($dog);
return $handler;
}
public function handle($request)
{
if ($this->nextHandler) {
return $this->nextHandler->handle($request);
}
return null;
}
}
/**
* Все Конкретные Обработчики либо обрабатывают запрос, либо передают его
* следующему обработчику в цепочке.
*/
class MonkeyHandler extends AbstractHandler
{
public function handle($request)
{
if ($request === "Banana") {
return "Monkey: I'll eat the " . $request . ".\n";
} else {
return parent::handle($request);
}
}
}
class SquirrelHandler extends AbstractHandler
{
public function handle($request)
{
if ($request === "Nut") {
return "Squirrel: I'll eat the " . $request . ".\n";
} else {
return parent::handle($request);
}
}
}
class DogHandler extends AbstractHandler
{
public function handle($request)
{
if ($request === "MeatBall") {
return "Dog: I'll eat the " . $request . ".\n";
} else {
return parent::handle($request);
}
}
}
/**
* Обычно клиентский код приспособлен для работы с единственным обработчиком. В
* большинстве случаев клиенту даже неизвестно, что этот обработчик является
* частью цепочки.
*/
function clientCode($handler)
{
foreach (["Nut", "Banana", "Cup of coffee"] as $food) {
echo "Client: Who wants a " . $food . "?\n";
$result = $handler->handle($food);
if ($result) {
echo " " . $result;
} else {
echo " " . $food . " was left untouched.\n";
}
}
}
/**
* Другая часть клиентского кода создает саму цепочку.
*/
$monkey = new MonkeyHandler();
$squirrel = new SquirrelHandler();
$dog = new DogHandler();
$monkey->setNext($squirrel)->setNext($dog);
/**
* Клиент должен иметь возможность отправлять запрос любому обработчику, а не
* только первому в цепочке.
*/
echo "Chain: Monkey > Squirrel > Dog\n\n";
clientCode($monkey);
echo "\n";
echo "Subchain: Squirrel > Dog\n\n";
clientCode($squirrel);
Результат выполнения:
Chain: Monkey > Squirrel > Dog Client: Who wants a Nut? Squirrel: I'll eat the Nut. Client: Who wants a Banana? Monkey: I'll eat the Banana. Client: Who wants a Cup of coffee? Cup of coffee was left untouched. Subchain: Squirrel > Dog Client: Who wants a Nut? Squirrel: I'll eat the Nut. Client: Who wants a Banana? Banana was left untouched. Client: Who wants a Cup of coffee? Cup of coffee was left untouched.
Пример из реальной жизни
Позволяет избежать привязки отправителя запроса к его получателю, предоставляя возможность обработать запрос нескольким объектам. Связывает в цепочку объекты-получатели, а затем передаёт запрос по цепочке, пока некий получатель не обработает его.
Пример: Пожалуй, самым известным применением паттерна Цепочка обязанностей (CoR) в мире PHP являются промежуточные обработчики HTTP-запросов, называемые middleware. Они стали настолько популярными, что были реализованы в самом языке как часть PSR-15.
Всё это работает следующим образом: HTTP-запрос должен пройти через стек объектов middleware, прежде чем приложение его обработает. Каждое middleware может либо отклонить дальнейшую обработку запроса, либо передать его следующему middleware. Как только запрос успешно пройдёт все middleware, основной обработчик приложения сможет окончательно его обработать.
Можно отметить, что такой подход - своего рода инверсия первоначального замысла паттерна. Действительно, в стандартной реализации запрос передаётся по цепочке только в том случае, если текущий обработчик НЕ МОЖЕТ его обработать, тогда как middleware передаёт запрос дальше по цепочке, когда считает, что приложение МОЖЕТ обработать запрос. Тем не менее, поскольку middleware соединены цепочкой, вся концепция по-прежнему считается примером паттерна CoR.
/**
* Классический паттерн CoR объявляет для объектов, составляющих цепочку,
* единственную роль – Обработчик. В нашем примере давайте проводить различие
* между middleware и конечным обработчиком приложения, который выполняется,
* когда запрос проходит через все объекты middleware.
*
* Базовый класс Middleware объявляет интерфейс для связывания объектов
* middleware в цепочку.
*/
abstract class Middleware
{
/**
* @var Middleware
*/
private $next;
/**
* Этот метод можно использовать для построения цепочки объектов middleware.
*/
public function linkWith($next)
{
$this->next = $next;
return $next;
}
/**
* Подклассы должны переопределить этот метод, чтобы предоставить свои
* собственные проверки. Подкласс может обратиться к родительской реализации
* проверки, если сам не в состоянии обработать запрос.
*/
public function check($email, $password)
{
if (!$this->next) {
return true;
}
return $this->next->check($email, $password);
}
}
/**
* Это Конкретное Middleware проверяет, существует ли пользователь с указанными
* учётными данными.
*/
class UserExistsMiddleware extends Middleware
{
private $server;
public function __construct($server)
{
$this->server = $server;
}
public function check($email, $password)
{
if (!$this->server->hasEmail($email)) {
echo "UserExistsMiddleware: This email is not registered!\n";
return false;
}
if (!$this->server->isValidPassword($email, $password)) {
echo "UserExistsMiddleware: Wrong password!\n";
return false;
}
return parent::check($email, $password);
}
}
/**
* Это Конкретное Middleware проверяет, имеет ли пользователь, связанный с
* запросом, достаточные права доступа.
*/
class RoleCheckMiddleware extends Middleware
{
public function check($email, $password)
{
if ($email === "admin@example.com") {
echo "RoleCheckMiddleware: Hello, admin!\n";
return true;
}
echo "RoleCheckMiddleware: Hello, user!\n";
return parent::check($email, $password);
}
}
/**
* Это Конкретное Middleware проверяет, не было ли превышено максимальное число
* неудачных запросов авторизации.
*/
class ThrottlingMiddleware extends Middleware
{
private $requestPerMinute;
private $request;
private $currentTime;
public function __construct($requestPerMinute)
{
$this->requestPerMinute = $requestPerMinute;
$this->currentTime = time();
}
/**
* Обратите внимание, что вызов parent::check можно вставить как в начале
* этого метода, так и в конце.
*
* Это даёт значительно большую свободу действий, чем простой цикл по всем
* объектам middleware. Например, middleware может изменить порядок
* проверок, запустив свою проверку после всех остальных.
*/
public function check($email, $password)
{
if (time() > $this->currentTime + 60) {
$this->request = 0;
$this->currentTime = time();
}
$this->request++;
if ($this->request > $this->requestPerMinute) {
echo "ThrottlingMiddleware: Request limit exceeded!\n";
die();
}
return parent::check($email, $password);
}
}
/**
* Это класс приложения, который осуществляет реальную обработку запроса. Класс
* Сервер использует паттерн CoR для выполнения набора различных промежуточных
* проверок перед запуском некоторой бизнес-логики, связанной с запросом.
*/
class Server
{
private $users = [];
/**
* @var Middleware
*/
private $middleware;
/**
* Клиент может настроить сервер с помощью цепочки объектов middleware.
*/
public function setMiddleware($middleware)
{
$this->middleware = $middleware;
}
/**
* Сервер получает email и пароль от клиента и отправляет запрос авторизации
* в middleware.
*/
public function logIn($email, $password)
{
if ($this->middleware->check($email, $password)) {
echo "Server: Authorization has been successful!\n";
// Выполняем что-нибудь полезное для авторизованных пользователей.
return true;
}
return false;
}
public function register($email, $password)
{
$this->users[$email] = $password;
}
public function hasEmail($email)
{
return isset($this->users[$email]);
}
public function isValidPassword($email, $password)
{
return $this->users[$email] === $password;
}
}
/**
* Клиентский код.
*/
$server = new Server();
$server->register("admin@example.com", "admin_pass");
$server->register("user@example.com", "user_pass");
// Все middleware соединены в цепочки. Клиент может построить различные
// конфигурации цепочек в зависимости от своих потребностей.
$middleware = new ThrottlingMiddleware(2);
$middleware
->linkWith(new UserExistsMiddleware($server))
->linkWith(new RoleCheckMiddleware());
// Сервер получает цепочку из клиентского кода.
$server->setMiddleware($middleware);
// ...
do {
echo "\nEnter your email:\n";
$email = readline();
echo "Enter your password:\n";
$password = readline();
$success = $server->logIn($email, $password);
} while (!$success);
Результат выполнения:
Enter your email: asd Enter your password: 123 UserExistsMiddleware: This email is not registered! Enter your email: admin@example.com Enter your password: wrong UserExistsMiddleware: Wrong password! Enter your email: admin@example.com Enter your password: letmein ThrottlingMiddleware: Request limit exceeded! Enter your email: admin@example.com Enter your password: admin_pass RoleCheckMiddleware: Hello, admin! Server: Authorization has been successful!