An Introduction to the Observer Pattern in PHP (
Page 1 of 4 )
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.Introduction
Design patterns can be hard to grasp sometimes. They're a fundamental part of advanced software development, and possibly this fact makes them even more intimidating to those developers starting to taste their real power. However, many things in software programming aren't as difficult as they seem at first glance, and that applies to learning design patterns as well.
True to form, over the development of numerous PHP applications, quite possibly you've been using some kind of design pattern, either because you needed to solve a specific problem by applying a well-known, proven solution, or simply due to your good coding habits. In either case, the good news is that you can become much more familiar with design patterns, as they can meet your programming requirements better than you may have initially thought.
Beyond the bunch of tongue-twisting buzzwords that "Singleton," "Factory" or "Iterator" can be, the truth is that one -- or all of them -- have already been part of your productive developer life.
Certainly, among the most popular design patterns, there's one that I think is especially interesting, particularly if you're used to writing a lot of object-oriented Web applications. In this case I'm speaking of the Observer pattern. Indeed, this pattern can be extremely useful in situations where a certain number of objects (or components) must have a clearly-delimited area of responsibility inside an application, and at the same time, need to send information to a centralized mechanism about all their changes occurring at runtime.
This is very convenient in many situations. It is especially useful when it comes to working with Web-based user interfaces and system loggers. In these cases there are different independent objects that need to reflect any eventual changes by notifying a core module, which will take a course of action in accordance with the relevance of these modifications.
In the examples that I mentioned before, the core module "observes" the distinct objects and decides what course of action must be taken, in response to the different changes reflected by the observed objects. In all the cases, the objects in question are only limited to performing their specific tasks, and are not responsible for making decisions beyond their scope. This facilitates their decoupling from the rest of the application.
Okay, after reading this simple introduction, I hope you'll be wondering how all this boring theory can be translated into functional PHP code. That's what I'm going to do in the course of this article, by introducing some friendly examples of how to implement the Observer pattern in PHP applications.
Are you ready? Let's get started.
