114Th.net

 
114. Design Patterns 95
So, what exactly qualifies a language as being object–oriented (OO)? Some
people believe that any language that has objects that encapsulate data and
methods can be considered OO. Others would also include polymorphism via
inheritance and access modifiers into the definition. The purists would probably
list dozens of pages of things they think an OO language must support,
such as exceptions, method overloading, reflection, strict typing, and more.
You can bet that none of these people would ever agree with each other
because of the diversity of OOP languages, each of them good for certain tasks
and not quite as good for others.
However, what most people would agree with is that developing OO software
is not only about the syntax and the language features but it is a state of
mind. Although there are some professionally written programs in functional
languages such as C (for example, PHP), people developing in OO languages
tend to give the software design more of an emphasis. One reason might be the
fact that OO languages tend to contain features that help in the design phase,
but the main reason is probably cultural because the OO community has
always put a lot of emphasis on good design.
This chapter covers some of the more advanced OO techniques that are
possible with PHP, including the implementation of some common design patterns
that are easily adapted to PHP.
When designing software, certain programming patterns repeat themselves.
Some of these have been addressed by the software design community
and have been given accepted general solutions. These repeating problems are
called design patterns. The advantage of knowing and using these patterns
is not only to save time instead of reinventing the wheel, but also to give developers
a common language in software design. You’ll often hear software developers
say, “Let’s use a singleton pattern for this,” or “Let’s use a factory pattern
for that.” Due to the importance of these patterns in today’s software development,
this section covers some of these patterns.
Gutmans_ch04 Page 94 Thursday, September 23, 2004 2:39 PM


114. Strategy Pattern
The strategy pattern is typically used when your programmer’s algorithm
should be interchangeable with different variations of the algorithm. For
example, if you have code that creates an image, under certain circumstances,
you might want to create JPEGs and under other circumstances, you might
want to create GIF files.
The strategy pattern is usually implemented by declaring an abstract
base class with an algorithm method, which is then implemented by inheriting
concrete classes. At some point in the code, it is decided what concrete strategy
is relevant; it would then be instantiated and used wherever relevant.
Our example shows how a download server can use a different file selection
strategy according to the web client accessing it. When creating the
HTML with the download links, it will create download links to either .tar.gz
files or .zip files according to the browser’s OS identification. Of course, this
means that files need to be available in both formats on the server. For simplicity’s
sake, assume that if the word “Win” exists in $_SERVER["HTTP_
USER_AGENT"], we are dealing with a Windows system and want to create .zip
links; otherwise, we are dealing with systems that prefer .tar.gz.
In this example, we would have two strategies: the .tar.gz strategy and
the .zip strategy, which is reflected as the following strategy hierarchy (see
Figure 4.3).
About | Archives | Links | Slr1 | 0230