Practical Php Patterns: Observer

This post is part of the Practical Php Pattern series.

Today's pattern is the Observer one. The intent of this pattern is breaking a [usually one-to-many] dependency between objects by making the set of objects act as Observers of a Subject one, which notifies them when its state changes or is affected someway.
The result of the application of the Observer pattern is an effective reduction of coupling: often notifications are sent to disparate objects which are thus prevented to becoming entangled.
This pattern is a form of publish/subscribe, where a Mediator between publishers and subscriber is not involved.

The classic application of the Observer pattern is in maintaining synchronization between views of the same data (part of the Mvc paradigm).
Another useful application is the connection of external infrastructure whose existence the subject should not rely on at all. For example Subject can be an object from the domain layer, which accepts as Observer-implementors objects from the upper layers (or their Adapters), to send them events to catch. The Observer and Subject interfaces in this case reside in the domain layer.
There is a broad spectrum where the implementation of this pattern can fit, whose extremes are named push and pull styles.

• In the pure push style, the Subject passes only the necessary parameters in the notification: this solution favors encapsulation of the Subject data.
• In the pure pull style, the whole Subject is passed to the update() method: this solution favors reusability of the Observers on different implementations or subclasses of Subject.

Obviously implementations can be a mix of this two pure solutions, for instance using a ValueObject as the update() parameter.
Another variability factor in implementation is how references are kept between the various objects of the graph. The only mandatory field references are the Observer collection, which is maintained in the Subject. The only advantage of keeping a reference to Subject in the Observer implementations is to not pass it in the notification, or check that the passed object is the subject where it was registered. Though, a mutual association would have to be maintained, and this can be tricky.

Participants

• Subject: interface that defines a protocol to set up a collection of Observers. Can sometimes be omitted by using the ConcreteSubject directly in method signatures.
• Observer: interface that defines a notification protocol.
• ConcreteSubject: stores the Observers and notifies them according to a contract, usually when its state changes (or when a notify() method is called).
• ConcreteObserver: performs business logic operations upon a notification from a Subject is received.

The code sample implements a pull-version of the pattern, but without Observers keeping a reference to Subjects to avoid a cyclic graph, which would add unnecessary complexity to the construction process. I have not used Spl interfaces because they would not add any value here. The addressed problem is how to get status updates of a User object (domain layer) to be sent to external social networks by infrastructure services.

<?php
/**
 * Needless to say, the Observer participant.
 * The chosen style is pure pull, so the whole User object
 * is passed to update(). User is en entity in the domain model
 * so the Observer will be probably dependent on it anyway.
 * The gained advantage is that User do not know the concrete
 * class of any of its Observers.
 */
interface UserObserver
{
    public function update(User $subject);
}

/**
 * Subject interface is omitted. The ConcreteSubject
 * is used instead directly.
 */
class User
{
    protected $_nickname;
    protected $_observers = array();
    protected $_status;

    public function __construct($nickname)
    {
        $this->_nickname = $nickname;
    }

    public function getNickname()
    {
        return $this->_nickname;
    }

    /**
     * Accepts an observer. Note that we really don't need
     * a detach() method.
     */
    public function attach(UserObserver $observer)
    {
        $this->_observers[] = $observer;
    }

    /**
     * Updates the status of the user (and notifies Observers.)
     */
    public function setStatus($text)
    {
        $this->_status = $text;
        $this->_notify();
    }

    public function getStatus()
    {
        return $this->_status;
    }

    /**
     * May be public if you want the Client to control
     * the notification generation.
     */
    protected function _notify()
    {
        foreach ($this->_observers as $observer)
        {
            $observer->update($this);
        }
    }
}

/**
 * This ConcreteObserver is passed the User.
 * It can extract from the argument the data it needs (pulling).
 */
class TwitterStatusObserver implements UserObserver
{
    /**
     * We should send the new status to twitter
     * which will mirror it, but to keep this a standalone
     * code sample we'll simply print it.
     */
    public function update(User $user)
    {
        $nickname = $user->getNickname();
        $status = $user->getStatus();
        echo "$nickname has changed its status to \"$status\"\n";
    }
}

// Client code
$user = new User('Giorgio');
$user->attach(new TwitterStatusObserver);
$user->setStatus('writing PHP code');