Design patterns are a way to create excellent OOP programs where update and changes can be made without having to rebuild your site from scratch. In many respects, they are the implementation of OOP principles into several different patterns for common uses. They are not templates but rather strategies for solving common programming problems with OOP.

The Pleasure of Doing Something Well

With PHP 5 (or some build of PHP 5) came a host of OOP structures including abstract classes, interfaces, class and method accessors and other OOP elements that moved PHP closer to an OOP language. Do you need OOP for writing effective and practical code in PHP? No. Will learning OOP make you a better programmer? Yes. Design patterns will make you a superior programmer.

If that doesn’t answer your question of Why bother with OOP or Design Patterns?; then this blog probably isn’t for you—at least now now. If you do derive pleasure in doing something well, all you need are a few OOP and Design Pattern principles and lots of patience with understanding advanced programming concepts. Here are a few OOP principles:

A class should only have a single responsibility

Strive for loosely coupled objects (classes)

Favor composition over inheritance

Subclass from interfaces and abstract classes

We’ll be discussing those and other OOP/Design Pattern principles with examples in PHP. The principles apply to all languages, and so if you’re familiar with them from one programming language you’ll find that they apply to PHP as well. The syntax may be different but the principles remain the same.

Is PHP Ready for Design Patterns and OOP?

When I first began writing design patterns I didn’t think that Internet languages were ready for advanced programming structures. After all, JavaScript and PHP were weakly typed languages (what we like to call dynamic languages), ActionScript had no private class accessors or even abstract classes, and SQL is so small that it didn’t make a lot of sense to even think about it possibly being bothered by design patterns. OOP and design patterns were structures for languages like Java and C++.

A lot of this thinking changed when in 1998 I read Tom Myers’ and Alexander Nakhimovsky’s book JavaScript Objects. They basically just went ahead and demonstrated how JavaScript could be structured along the lines of OOP. They didn’t make a big deal about it; they just did it. Their work reminded me of the observation that upon structural analysis, bees should not be able to fly. However, the bees apparently did not read the reports and went ahead and flew anyway.

With PHP 5, too many structures had been built in to suggest that the language’s framers were not thinking about OOP structures. In 2006, IBM sponsored a post, Five common PHP design patterns, and they later followed it up with another, Five more PHP design patterns. To my way of thinking, if IBM thinks that design patterns can be profitably used with PHP, who am I to get all obsessive and claim otherwise? Who indeed?

Some critics have claimed that design pattern and OOP enthusiasts try to “force” OOP and design patterns on languages where they don’t belong. That’s probably not true on several levels. Professional programmers (i.e., those with computer science and computer engineering degrees) simply get used to a certain programming style—most likely OOP. Then, like Nakhimovsky and Myers (who were professors at Colgate University), they just start using the structures they’re accustomed to programming with on Internet languages like JavaScript. They quickly demonstrate that OOP structures work just fine and have the same benefits that they have for languages like Java, C++ and SmallTalk.

With PHP 5, it’s very difficult to argue with, or even take seriously, those who want to avoid OOP and design patterns because they being “forced on PHP.” Even in pre-PHP 5 times, certain structures could be applied to PHP and they reaped the benefits of these more advanced programming structures. So, we’re not going to spend a lot of time arguing about whether design patterns can be applied to PHP or not. Like the bee, we’re just going to fly with it.

A Short History of Design Patterns

Design patterns were developed at the encouragement of both developers and businesses that used software. The one constant in software is change. So, knowing that, developers set out to find how they could create programs that could be developed collaboratively, be changed by adding new modules or changing existing ones and could be reused. The first such development goes back to Xerox Parc in 1979 with the introduction of the Model-View-Controller (MVC). This separated key elements that had been fused together by programming practices and opened the door for greater flexibility. The real jump came in 1995 with the publication of Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Generally known as The Gang of Four (or GoF) Gamma and his colleagues created a catalog of 23 Design Patterns that we will be examining on this blog, written in PHP.

A Little About Us Years ago, a guy named Mark Winstanley and I wrote a book together on using Flash with various kinds of middleware for backend work, Server-Side Flash. Part of my contribution was to write the chapter on Flash and PHP, and that’s how I discovered PHP. This was back in 2000. Since that time, I’ve been teaching a university class on the basics of PHP up to the point of creating and using tables in MySQL before then end of the term.

This term (Spring 2010) I was able to put together an entire course just for PHP and OOP and advanced database work (working with relational databases). We’re using PHP 5.x with the ‘x’ depending on whether we’re using the university server or the one that’s built into my Snow Leopard Mac. Some time ago I tried my hand at writing some design patterns in PHP, and I found that it was possible; so we got the idea of writing a PHP blog. On this blog, my collaborator (Chandima Cumaranatunge) and I will be using PHP 5 but will probably switch to PHP 6 as it becomes more standardized. Up until now, virtually everything we’ve done with design patterns has been done with ActionScript 3.0 and Flash/Flex (Flash Builder). We had written a book, ActionScript 3.0 Design Patterns: Object-Oriented Programming Techniques with O’Reilly Publishers and decided to create a blog on the same topic. (So now you know we really come from a different universe—or at least a parallel one.)