Having seen the Strategy pattern, it’s time to look at two related patterns, which use the same notion of a unified API to control a collection of (possibly) unrelated objects.

Both of these patterns give us the opportunity to turn our applications into something much “bigger” than we origionally planned, with minimal effort required to re-write code.

1)

The Adapter Pattern

The adapter pattern is conceptually a bit like an international power adapter that you take on holiday, so you can plug in your electric shaver or hairdryer to the local power supply.

You use an adapter pattern when you’ve already built a class to perform some task but now need to an alternative class (with perhaps a very different API) to perform the same function.

It’s similar to the Strategy pattern but where the Strategy pattern deals with hiding a set of algorithms behind a common interface, the Adapter pattern deals with hiding a collection of objects behind an interface.

Note: there are two variants of the Adapter pattern: the Object Adapter (which is what we’re talking about here) and the Class Adapter (which requires multiple inheritance, not supported by PHP).

It’s best demonstrated with an example. We’ve looked at the MVC Pattern.

Working, in general, from that example, which used MySQL as the target database, imagine now that we have customers for our “Products” application. Customer A says “I love it but I use Oracle”. Customer B says “I want to deploy you application in my N-Tier environment using SOAP to provide your application with data”.

So here we have two problems. For Oracle, simple database abstraction isn’t enough, because MySQL uses an SQL syntax which often varies significantly from Oracle. For example, imagine we want limit the number of rows we return from a SEL

The Observer Pattern
The observer pattern, also known as subject-observer and listener, is a more complicated but very prevalent and useful pattern. Anyone who has done event handling in Java knows this pattern, every kind of event listener is an observer to one subject or another - the keyboard, a window, a mouse, etc.

The pattern describes how to attach any number of observers to a subject, which can then act on events that occur involving the subject. For example, this pattern is available in the PEAR Log:: package, allowing you to monitor log data with an observer object and take action - such as sending an email page on any critical errors - on certain kinds of log messages.

Here's a simple usage of this implementation of the observer pattern:

The Observer Pattern is designed to help cope with one to many relationships between objects, allowing changes in an object to update many associated objects. It provides a powerful mechanism to extend our applications, in terms of how they respond to events, without needing alter existing (and working) code.

We’ll take a simplified look at how the observer pattern might be used in a typical PHP forum application then suggest other uses for the observer pattern

Under Observation

1) The Observer pattern is defined by the Gang of Four in Design Patterns as behavioural pattern - that is one we can use to modify the behaviour of our applications. It’s regarded as being so useful, that Sun bothered to implement it in the Java API (see Observable and Observer).

The basic principle behind the observer pattern is if you have some object, such as a Post object for a forum system, you can have other objects, such as a Mailer object, act as an observer and respond to any changes in the Post object, such as emailing relevant forums users that a new post has been added to the thread they were subscribed to.

Conceptually, the Observer pattern in something like a trigger in a database, which runs a stored procedure when a table row is modified for example (we won’t go too far with this analogy though).

Normally we might implement the mailing functionality in the Post object itself but what if later we want add further “events” to Post, when a new post is made, such as adding an entry to our forums RSS feed for example? And how many more things might we want to add in future?

The observer pattern provides us the mechanism to add such functionality without needing to alter the Post object.

The is easiest to see will some some example code.

First we define two interface classes; an Observable class which will be inherited by the Post class and allows it to become the subject of observation and an Observer class which will be inherited by the classes used to observer Post.

When I’ve talked about managing large applications in the past, I was criticized for going through many different options and then telling you that you can decide which one you liked the best. I suppose I might be afraid I’d make the wrong choice too, so in this article, I’m going to explain what I would use in my totally sweet large applications, but just know, there are lots of smart people who have different opinions.

The first talk I gave after arriving at Yahoo! was entitled Maintainable JavaScript (video). As with most topics I write or speak about, I didn’t think it would be terribly controversial. The basis of the talk is that hacking around on your own and writing code in an enterprise environment are two different things. Web developers are truly unique in that none of us learned what we know in school; we all began as hobbyists one way or another and taught ourselves most (if not all) of what we know.