Практические шаблоны PHP: посредник

В любом домене есть много операций, которые не подходят для существующих объектов, смоделированных из реальности, и если их принудительно использовать как методы уже существующего класса, это добавит зависимость к возможно не связанному сотруднику. Такой подход приведет к созданию сети
тесно взаимосвязанных объектов Colleague, а не к
коду Ravioli.мы хотим работать с Объекты «Коллеги» должны быть слабо связаны, чтобы избежать необходимости ссылаться на них в целом в любое время, когда один из них требуется от Клиента.

Решение этой распространенной проблемы заключается в реализации шаблона посредника. Когда отношения объекта и зависимости начинают конфликтовать с его деловой ответственностью (причина, по которой он был создан в первую очередь), мы должны ввести посредника, который
координирует рабочий процесс между связанными объектами, освобождая их от этой формы связи; могут быть установлены зависимости от Коллег по отношению к Посреднику и / или от Посредника по отношению к Коллегам. Оба направления этих зависимостей могут быть нарушены с помощью интерфейса
AbstractColleague или
AbstractMediator, если необходимо.

Ни один объект не является островом , и каждый объект в приложении должен взаимодействовать с другими частями графа, чтобы выполнить свою работу и решить
одну проблему . Поскольку взаимодействия являются источником взаимосвязи, посредник является одним из наиболее эффективных способов ограничения этого, хотя при злоупотреблении это может затруднить написание связных классов.

В качестве практического примера, Услуги в
доменно-управляемом дизайне являются посредниками между сущностями. Для
php- связанного примера
Zend_FormВозможности декорирования и фильтрации на самом деле являются реализацией простого посредника между экземплярами Zend_Form_Decorator и Zend_Filter. То же самое касается проверки с использованием объектов Zend_Validate. Создание каждого фильтра со ссылкой на следующий создаст
цепочку ответственности, потенциал которой не будет использован.

Когда Посредник должен прослушивать события Коллеги, он часто реализуется как Наблюдатель, в результате чего создается
объект классной доски, на котором одни Коллеги пишут, а другие читают. События передаются Посреднику от Коллеги, прежде чем он доставляет их другим подписавшимся Коллегам. Никто из них не знает других коллег: эта архитектура успешно используется в
ДодзёБиблиотека JavaScript поставляется с Zend Framework.

Еще одним преимуществом этого шаблона является
изменение объектов, участвующих в вычислении: эта цель может быть достигнута путем настройки посредника по-разному, тогда как создание взаимосвязанных объектов может быть несвязной операцией, а отношения сотрудничества будут разбросаны по разным контейнерам или фабрикам.

участники

• Коллега : фокусируется на своей ответственности, общаясь только с Посредником или Абстрактным Медиатором.
• Посредник : координирует работу набора, составленного несколькими Коллегами (AbstractColleagues).
• AbstractMediator , AbstractColleague : дополнительные интерфейсы, которые отделены от фактической реализации этих ролей. Может быть более одной роли AbstractColleague.

Пример кода реализует процесс фильтрации для ввода формы, который напоминает функцию Zend_Form_Element.

<?php
/**
 * AbstractColleague.
 */
interface Filter
{
    public function filter($value);
}

/**
 * Colleague. We decide in the implementation phase
 * that Colleagues should not know the next Colleague
 * in the chain, resorting to a Mediator to link them together.
 * This choice succesfully avoids a base abstract class
 * for Filters.
 * Remember that this is an example: it is not only
 * Chain of Responsibility that can be alternatively implemented
 * as a Mediator.
 */
class TrimFilter implements Filter
{
     public function filter($value)
     {
         return trim($value);
     }
}

/**
 * Colleague.
 */
class NullFilter implements Filter
{
     public function filter($value)
     {
         return $value ? $value : '';
     }
}

/**
 * Colleague.
 */
class HtmlEntitiesFilter implements Filter
{
     public function filter($value)
     {
         return htmlentities($value);
     }
}

/**
 * The Mediator. We avoid referencing it from ConcreteColleagues
 * and so the need for an interface. We leave the implementation
 * of a bidirectional channel for the Observer pattern's example.
 * This class responsibility is to store the value and coordinate
 * filters computation when they have to be applied to the value.
 * Filtering responsibilities are obviously a concern of
 * the Colleagues, which are Filter implementations.
 */
class InputElement
{
    protected $_filters;
    protected $_value;

    public function addFilter(Filter $filter)
    {
        $this->_filters[] = $filter;
        return $this;
    }

    public function setValue($value)
    {
        $this->_value = $this->_filter($value);
    }

    protected function _filter($value)
    {
        foreach ($this->_filters as $filter) {
            $value = $filter->filter($value);
        }
        return $value;
    }

    public function getValue()
    {
        return $this->_value;
    }
}

$input = new InputElement();
$input->addFilter(new NullFilter())
      ->addFilter(new TrimFilter())
      ->addFilter(new HtmlEntitiesFilter());
$input->setValue(' You should use the <h1>-<h6> tags for your headings.');
echo $input->getValue(), "\n";