Introduction
One of the real challenges in building any type of framework, core or application is making it possible for the developers to hook into the business logic at specific points. Since PHP is not event based, nor it works with interrupts you have to come up an alternative.

The test case
Lets assume we are the main developers of a webshop framework. Programmers can use our framework to build complete webshops. Programmers can manage the orders that are placed on the webshop with the order class. The order class is part of our framework and we don’t want it to be extended by any programmer. However we don’t want to limit to programmers in their possibilities to hook into the orders process.

For example programmers should be able to send an email to the webshopowner if an order changes from one specific delivery status to another. This functionality is not part of the default behavior in our framework and is custom for the progammers webshop implementation.

Like said before, PHP doesn’t provide interrupts or real events so we need to come up with another way to implement hooks into our application. Lets take a look at the observer pattern.

Implementing the Observer pattern
The observer pattern is a design-pattern that describes a way for objects to be notified to specific state-changes in objects of the application.

For the first implementation we can use SPL. The SPL provides in two simple objects:

echo‘Mail sended to the secratary to help her remember to call our customer for a survey.’;

}

}

}

}

$oOrder = new Order(26012011);

$oOrder->attach(new OrderStatusHandler());

$oOrder->updateStatus(Order::STATUS_DELIVERED);

$oOrder->delete();

?>

There are several problems with the implementation above. To most important disadvantage is that we have only one update method in our observer. In this update method we don’t know when and why we are getting notified, just that something happened. We should keep track of everything that happens in the subject. (Or use debug_backtrace… just joking, don’t even think about using it that way ever!).

Taking it a step further, events
Lets take a look at the next example, we will extend the Observer implementation with some an additional parameter for the eventname that occured.

Finishing up, optional data

<?php

/**

* Any object whose state may be of interest, and in whom another object may register an interest

*

* @package Interface

* @version $Id$

*/

interface Observable_Interface

{

/**

* Attach, attaches an observer that will be notified on specific events

*

* @return void

*/

publicfunction attachObserver(Observer_Interface $oObserver);

/**

* Detach, detach an observer

*

* @return boolean

*/

publicfunction detachObserver(Observer_Interface $oObserver);

}

/**

* Any object that wishes to be notified when the state of another object changes

echo‘Mail sended to the secratary to help her remember to call our customer for a survey.’;

}

}

}

}

$oOrder = new Order(26012011);

$oOrder->attachObserver(new OrderStatusHandler());

$oOrder->updateStatus(Order::STATUS_DELIVERED);

$oOrder->add();

?>

Now we are able to take action on different events that occur.

Disadvantages
Although this implementation works quite well there are some drawbacks. One of those drawbacks is that we need to dispatch an event in our framework, if we don’t programmers can’t hook into our application. Triggering events everywhere give us a small performance penalty however I do think this way of working gives the programmers a nice way to hook into your application on those spots that you want them to hook in.

Just for the record
Notice that this code is just an example and can still use some improvements, for example: each observer is initialized even it will maybe never be notified, therefore I suggest to make use of lazy in some cases for loading the objects. There are other systems to hook into an application, more to follow!