Datasheet

CHAPTER 1 INTRODUCING SYMFONY, CAKEPHP, AND ZEND FRAMEWORK

DESIGN PATTERNS IN WEB FRAMEWORKS

There are certain abstractions that can be transported between applications in order to make the

development process faster. This section takes a closer look at these abstractions and the way they

shape the web application frameworks.

It is not absolutely necessary to understand design patterns in order to start working with frame-

works, so if you are bored, you can skip to the next chapter and come back here later. However,

design patterns are fairly fundamental to these frameworks and application development as a whole,

so we insist that you really come back here if you decide to skip this section now.

What Is a Design Pattern?

The deﬁ nition of design pattern states that it is a general solution to a commonly occurring problem

in software design. There is really not much more formal foundation because design patterns are a

generally practical means that make up for a lack in formal mechanisms. Most often they are cre-

ated when programming languages do not provide abstract mechanisms that become undeniably

useful during the development of real-world applications.

A good analogy for design patterns is the game of chess. A novice player needs just to know the

rules. It’s like learning the basic syntax of a programming language. Still, knowing how a bishop

moves doesn’t make you a successful chess player, just like knowing how to open braces doesn’t

make you a PHP programmer. Skilled players are able to predict a few moves forward and respond

with a winning scheme. That’s like an experienced programmer who can, in fact, produce working

software.

As you begin to master the game of chess, you begin to see patterns emerging. You can barely glance

at the chessboard to classify the situation into one of these patterns and provide a proven response,

both for present and future risks. You can perceive these patterns just intuitively, or you may try to

name them. It’s the same with software design patterns: when you are truly proﬁ cient, you use them

all the time. There is a good chance that you have used some of them without even knowing it.

Naming design patterns is not necessary, but is indeed good for two things. First is an aid for think-

ing with patterns, because when you name something abstract, it is much easier to implement it in

practice. Then you may further analyze this pattern, draw diagrams of it, and take full advantage

of it. And the other thing is that you can share your experience. Chess players love to talk about

various openings and gambits, and programmers can learn a lot by exchanging knowledge of design

patterns as well.

And even more important, if you want another programmer to add some functionality to a ﬁ xed

class and then tell him to use the Decorator pattern, you can expect that it will be done the way you

want it rather than with a random makeshift solution. Thus design patterns have a great potential

for preventing future problems.

Model-View-Controller as the Main Structural Design Pattern

Web frameworks take advantage of most, if not all, design patterns. However, MVC is the abso-

lute structural backbone of all frameworks. The main idea of MVC is dividing the application

into three layers:

c01.indd 14c01.indd 14 1/24/2011 5:45:18 PM1/24/2011 5:45:18 PM