Datasheet

Chapter 1: Understanding Design Patterns
5
It was once said that every single piece of music that could be written already has been. Now, new music
creation is just the rearranging of those particular sets of notes to different tempos and speeds. It ’ s the
same with general software development, barring a few major groundbreaking exceptions. The same
problems come up repeatedly and require common solutions. This is exactly what Design Patterns
are: reusable solutions for these common problems.
No book mentioning Design Patterns would be complete without the reference to the Gang of Four : Erich
Gamma, Richard Helm, Ralph Johnson, and John Vlissides, authors of the original Design Patterns book.
After a considerable amount of time in the field, they started noticing particular patterns of design
emerging from various development projects. Collectively, they gathered these ideas together to form the
initial Design Patterns concept. Recognizing these as templates for future development, they were able to
put them into an easy - to - understand reference with digestible segments for large, complex programming
concepts.
While Design Patterns can encompass many things — from interface design to architecture, and even
marketing and metrics — this particular book will focus on development language construction using
Object Oriented Programming.
A problem in software design consists of three parts:
The “ what ” is considered the business and functionality requirements.
The “ how ” is the particular design that you use to meet those requirements.
The “ work ” is the actual implementation, or the “ how ” put into actual application and practice.
Design Patterns fit into the “ how ” of this process, and as a result, this book describes the “ how ” of
solving these problems as well as portions of the “ work ” necessary to make these solutions successful.
You can picture PHP as the vehicle behind the “ why ” of the problem solving. Once you know “ what ”
the software needs to do, and you ’ ve designed “ how ” it can do it, the “ work ” becomes a lot easier with a
lot less refactoring.
I can ’ t stress this enough: the PHP language, your grasp of it and the way you understand its intricacies
is not the focus of this book. Instead, I bring common, time tested methodologies into focus, describe
them, and relate them to PHP.
Patterns naturally start to come out of software development, as you saw in the example. However,
having a full playbook that references existing patterns can make the architecture planning faster and the
choices better. As an added bonus, programmers coming from different software realms may recognize
the pattern and just have to adapt to the specifics of the language. Having a clear set of patterns in your
application may also help new members of your team grasp your project, lowering your ramp - up time.
Design Patterns Are Around You All the Time
You ’ ve seen how Steve ’ s team was able to grasp basic patterns in their software and create reusable
items. You may also be able to draw parallels to your own software development now. How many times
have you created the same user login and authentication system using your user class? Do you have a
db() function sitting around somewhere that you favor? These are examples of how you ’ ve already
been using patterns.
❑
❑
❑
c01.indd 5c01.indd 5 7/17/09 12:17:44 PM7/17/09 12:17:44 PM