PHP Freaks

Note

Originally, this tutorial was huge, covering both Introduction and pattern descriptions. Instead I am now posting the Introduction, the pattern descriptions will be posted individually.

Introduction

Implementing Design Patterns is gradually getting more common in the PHP world. The hype around Ruby on Rails, which is based on the Model-View-Controller architectural pattern, has spawned a generation of PHP based frameworks which embrace this pattern also, paving the way for others to embrace design patterns in general in their PHP applications.

Much about Design Patterns is about interpretation (which is why it is often so heavily discussed), so please do not take everything I write for granted: deduct your own conclusions, get your own interpretation.

1 What are design patterns?

1.1 Where do patterns come from?

Originating from architectural design (as in design of buildings), when design patterns crossed over to computer programming in the 1980’s, only a small group of people using a language called “SmallTalk” were applying them. In 1995, a group of four authors released a book called “Design Patterns: Elements of Reusable Object-Oriented Software”.

The four authors where nicked the “Gang of Four”. SmallTalk, but also C++ where the languages applying design patterns at that time. It is still the most respected book on design patterns to this date. “Gang of Four” (abbr. GoF) is also commonly used to refer to the book, rather than the authors.

Soon after, 'Gurus' such as Martin Fowler started publishing their own works, perhaps most notably “Patterns of Enterprise Application Architecture” (abbr. PoEAA). By then, most books where using Java in their examples. The Java community has played a big part in the evolution of Design Patterns, not in the last place thanks to efforts from Alur et al. with their “J2EE Core Patterns”.

1.2 What are they?

But what exactly are these “Design Patterns” I keep rambling on about?

If you’re an experienced coder, you’ve more than likely run into problems that you solve in a, for you, standard way. Design patterns are more or less the description of that: a problem and a solution (or more of them), in the context of a system.

The GoF describes patterns to be made up of four parts, not mentioning “context”, and adding “pattern name” and “consequences”. However, they also provide this description of the patterns in their book:

“The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.”

Design patterns catalogs do not just provide problems and their solution, but also provides named handles for them. This makes it possible to communicate with your fellow developers referencing patterns without having to lay it out.

But pattern descriptions often encompass multiple solutions to the same problem. So even if you are talking about the same problem, you may be talking about a different solution, with different implications.