Home arrow PHP arrow Page 3 - An Introduction to the Observer Pattern in PHP

Adding a basic error logger - PHP

If you have reached the point in your programming life where you are using design patterns, you will want to read this article. The first of a three-part series, it covers the Observer pattern, which can be just the thing for situations where objects need to send information to a centralized mechanism.

  1. An Introduction to the Observer Pattern in PHP
  2. Building a practical example
  3. Adding a basic error logger
  4. Applying the Observer design pattern
By: Alejandro Gervasio
Rating: starstarstarstarstar / 15
July 17, 2006

print this article



Adding a basic error logger to the message handling application that you learned before is in fact a straightforward process, which can be achieved by defining a simple error logging class. The code listed below illustrates how the application looks after including a new “ErrorLogger” class. Please, take a look:

  // define 'MessageConverter' class
  class MessageConverter{
    private $message;
    public function __construct($message){
            throw new Exception('Input message must be a
    // return uppercased message
    public function getMessage(){
        return $this->message;
  // define 'MessageSaver' class
  class MessageSaver{
    const LENGTH_ERROR='Invalid length of message.';
    const WORD_ERROR='Message contains invalid words.';
    private $msgPath='defaultPath/messages.txt';
    private $badWords=array('BAD WORD1','BAD WORD2','BAD WORD3');
    private $errorLogger;
    private $msgConv;
    public function __construct(MessageConverter $msgConv){
        $this->errorLogger=new ErrorLogger();
    public function save(){
        // check for message length
            // log message's length error by ErrorLogger object
        // check for bad words
            // log word error by ErrorLogger object
        // checking was passed, then save message to file
            throw new Exception('Error opening messages file.');
  // define 'ErrorLogger' class
  class ErrorLogger{
    private $mailAdmin='mailadmin@domain.com';
    // log error to file
    public function logLengthError($errorMsg){
            throw new Exception('Could not log error to
    // email error to system administrator
    public function logWordError($errorMsg){
        if(!mail($this->mailadmin,$errorMsg,'Message is not
            throw new Exception('Could not email error to system

Now, the message handling application's functionality is increased, because I added to it a basic error logging class. As you can see, this class will log errors either to the system logger or by email to the corresponding system administrator, according to the type of error raised at runtime.

Based on the prior improved structure, the message handling application eventually might be used as follows:

    // instantiate 'MessageConverter' object
    $msgConv=new MessageConverter('This message will be converted
to uppercase!');
    // instantiate 'MessageSaver' object
    $msgSaver=new MessageSaver($msgConv);
    // save message to file
  catch(Exception $e){
    echo $e->getMessage();

At this point, I constructed a simple message saving system, which is comprised basically of three independent classes. It is capable of delegating program control to an error logger when things go wrong, in this way limiting the scope of each involved object.

Nevertheless, even when all the classes seem to fit each other quite well, there’s a problem that can easily break down the model of the whole application. Notice how the definition of the “MessageSaver” class has been convoluted with messy code, since the class now has to deal with the direct instantiation of an “ErrorLogger” object, in order to perform all the error login operations.

This is truly undesirable, particularly if I want to keep all the objects decoupled from the rest of the application. It gets even worse if I aggregate new classes to the application, while trying to maintain the correct scope of all the objects. Certainly, I would end up with a set of classes, which should perform the instantiation of other objects, quickly breaking down the model of highly independent classes.

Thus, the question is: can I restructure the message handling application in such a way that it can work with decoupled objects, while maintaining the same functionality? Fortunately, the answer is yes, and here’s where the Observer pattern comes in.

In the upcoming section, I’ll show you how to use this pattern to solve the issues that I discussed before. Therefore, click on the link below to learn more.

>>> More PHP Articles          >>> More By Alejandro Gervasio

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Hackers Compromise PHP Sites to Launch Attac...
- Red Hat, Zend Form OpenShift PaaS Alliance
- PHP IDE News
- BCD, Zend Extend PHP Partnership
- PHP FAQ Highlight
- PHP Creator Didn't Set Out to Create a Langu...
- PHP Trends Revealed in Zend Study
- PHP: Best Methods for Running Scheduled Jobs
- PHP Array Functions: array_change_key_case
- PHP array_combine Function
- PHP array_chunk Function
- PHP Closures as View Helpers: Lazy-Loading F...
- Using PHP Closures as View Helpers
- PHP File and Operating System Program Execut...
- PHP: Effects of Wrapping Code in Class Const...

Developer Shed Affiliates


Dev Shed Tutorial Topics: