An in-depth analysis of the mediator pattern in PHP design patterns

An in-depth analysis of the mediator pattern in PHP design patterns_PHP Tutorial

WBOY

Release： 2016-07-21 15:07:16

Original

1029 people have browsed it

Mediator pattern, the purpose of this pattern is to encapsulate the interaction between a group of objects and prevent the objects from interfering with each other. The Mediator (Mediator) acts as an intermediate convergence point between Colleague objects (Colleague). Colleague objects should be loosely coupled to avoid one object pointing directly to another object. In the mediator mode, when the relationships and dependencies of objects conflict, we can use the mediator to coordinate the workflow between coupled objects. Dependencies can be established from colleagues to the mediator or from the mediator to colleagues in both directions. Dependencies can be broken using AbstractColleague or AbstractMediator.

Objects are not isolated, they must cooperate with each other to complete tasks. Although the mediator pattern can limit the interaction between objects, if abused, it can make writing aggregate classes very difficult. To give a practical example, services in Domain-Driven Design are mediators between entities. To give another PHP-related example, the Zend_Form decoration and filtering functions can actually be seen as a simple mediator between Zend_Form_Decorator and Zend_Filter instances, both of which use Zend_Validate objects for validation.

When the mediator must listen to events on colleague objects, it is usually implemented as an Observer, producing a blackboard object for some colleagues to write and others to read. Events from colleagues are pushed to the mediator, who then forwards them to other subscribed colleagues. Colleagues do not need to know each other. This architecture is successfully used in the Dojo JavaScript library released with the Zend Framework. Another benefit of this pattern is that the changes to the object are contained in the calculation method. This can be achieved by configuring different mediators, but instantiating related objects will be a loose operation, and the collaborative relationship between different containers and factories will is decentralized.

Participants:
◆Colleague: The point is its responsibilities, it only communicates with one mediator or AbstractMediator.
◆Mediator: Work together with multiple Colleagues (AbstractColleagues).
◆AbstractMediator, AbstractColleague: Optional interfaces decoupled from the real implementation of these roles, there may be more than one AbstractColleague role.
The following code implements a form input filtering process, similar to the Zend_Form_Element function.

Copy code The code is as follows:

        /**
     * 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);
}
    }

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

    /**  <br>     * The Mediator. We avoid referencing it from ConcreteColleagues  <br>     * and so the need for an interface. We leave the implementation  <br>     * of a bidirectional channel for the Observer pattern's example.  <br>     * This class responsibility is to store the value and coordinate  <br>     * filters computation when they have to be applied to the value.  <br>     * Filtering responsibilities are obviously a concern of  <br>     * the Colleagues, which are Filter implementations.  <br>    */  <br>    class InputElement  <br>    {  <br> protected $_filters;  <br> protected $_value;  <br><br> public function addFilter(Filter $filter)  <br> {  <br>     $this->_filters[] = $filter;  <br>     return $this;  <br> }  <br><br> public function setValue($value)  <br> {  <br>     $this->_value = $this->_filter($value);  <br> }  <br><br> protected function _filter($value)  <br> {  <br>     foreach ($this->_filters as $filter) {  <br>  $value = $filter->filter($value);  <br>     }  <br>     return $value;  <br> }  <br><br> public function getValue()  <br> {  <br>     return $this->_value;  <br> }    <br>    }  <br><br>    $input = new InputElement();  <br>    $input->addFilter(new NullFilter())  <br>   ->addFilter(new TrimFilter())  <br>   ->addFilter(new HtmlEntitiesFilter());  <br>    $input->setValue(' You should use the <h1>-<h6> tags for your headings.');  <br>    echo $input->getValue(), "n";<br>