PHP Patterns: Introduction
Introduction
Even if you have never set eyes on a pattern catalog in your life, you have probably come
across the phrase design patterns in recent years. You may even have assumed that
patterns were yet another fad. After the turn of the century it suddenly seemed that
patterns were everywhere, and PHP was not immune. Yet with increased support for objects
in PHP 5, design patterns are set to become an essential tool for the PHP coder.
In this article I introduce patterns in the context of PHP 5. From a basic definition,
I work through to a short example. I also describe the structure of a pattern and explain
some of the principles that the classic patterns promote and deploy.
Design Pattern Basics
In order to get a handle on patterns, we need to cover some introductory ground. This
section provides you with the kind of overview that will get you through the meet and
greet cocktail party on a geek cruise. Don’t worry, we’ll move on to the beer and pizza
later.
What is a Design Pattern?
As a coder you must encounter some requirements time and time again according to your
business domain. The need to handle more than one database, for example, or to process an
HTTP request so that the appropriate operations are performed in response. Such
requirements demand solutions, and the solutions define the shapes and structures in your
code. The first time you see the problem, you may have to think long and hard before a
solution presents itself. When you see it again, you can refine the solution, or even
replace it – selecting something neater perhaps, or something that has a more benign
effect on your system as a whole.
After a while you will develop a feel for the forces at play in the systems you create,
and craft a set of techniques to field them. Each technique you deploy will create new
demands. If you centralize HTTP request processing, for example, you need a strategy to
dispatch an appropriate view with your response. If, on the other hand, you process
requests on a page by page basis the views self-select, but you need to be careful to
resist the temptation to cut and paste code from page to page, and instead carefully
factor out duplication.
Now that you have this knowledge, how easy is it to communicate to a new team member?
Without a name for a technique, how do you describe it in a sentence standing at a white
board? If you leave a project, how clear will those carefully crafted shapes in your
system be to your successor? When you learned this stuff the hard way, how likely is it
that someone else had already traveled the same route as you? How much time would you
have saved if their conclusions had been named and written down?
If you design systems you work with patterns of design. Design pattern catalogs are
simply a distillation of the neatest, the most common, the most useful. There is no
mystery beyond the magic of naming and inscription, and yes, that is powerful magic.
This is one of my favorite design pattern definitions:
In the world of software, a pattern is a tangible manifestation
of an organization’s tribal memory.(Grady Booch, Core J2EE Patterns)
Design patterns are just that. They are solutions to common problems, written down so
that they can be easily shared by others in a community. This means that the lessons they
inscribe do not need to be relearned over and over again as the same problems are
independently encountered.
On its own, though, this is not quite enough. A less inspiring definition might go
something like this:
A design pattern describes a problem together with one or
more suggested solutions in the context of a system.
These three elements, problem, solution and context, are all
essential components of a pattern.
Problem
Any experienced programmer knows that the real work often lies in the finding not the
fixing of a bug. So it is with design patterns. An understanding of the problem should
precede the selection of the tool that addresses it. A design pattern kicks off with a
summary and a discussion of the problem that is to be addressed.
Critics of design patterns occasionally argue that techniques are deployed
inappropriately and indiscriminately. This is probably a fair criticism of pattern
deployment, but not necessarily a charge that can be laid at the door of the design
patterns themselves. A pattern places immediate focus upon the the problem that its
solution addresses. A good coder will therefore devote as much care to studying the
shapes and smells in code that seem to call for a pattern’s deployment as he will to the
process of deployment.
Here’s the Gang of Four on the subject:
Another important change over the past year has been a greater emphasis on the problem
that a pattern solves. It’s easiest to see a pattern as a solution, as a technique that
can be adapted and reused. It’s harder to see when it is appropriatePublished: February 23rd, 2006 at 8:15
Categories: Uncategorized
Tags: Advanced, Articles, Design Patterns, Expert, Intermediate, PHP5
One comment to “PHP Patterns: Introduction”
September 7th, 2010 at 10:10 pm
Matt, thanks a lot for the excerpts from your book.
I was _trying_ to practice Object Generation patterns that you discussed. I was trying to analyze the UML Class-Diagram for Zend_Log, can you please checkout http://stackoverflow.com/questions/3655209/is-uml-class-diagram-of-zend-log-correct and let me know if I laid out the Zend_Log correctly?
Regards!