PHP Pattern Principles, Page 4
One problem for which there is no pattern is the unnecessary or inappropriate use of patterns. This has earned patterns a bad name in some quarters. Because pattern solutions are neat, it is tempting to apply them wherever you see a fit, whether they truly fulfill a need or not.
The eXtreme Programming methodology offers a couple of principles that might apply here. The first is “You arent going to need it” (often abbreviated to YAGNI). This is generally applied to application features, but it also makes sense for patterns.
When I build large environments in PHP, I tend to split my application into layers, separating application logic from presentation and persistence layers. I use all sorts of core and enterprise patterns in conjunction with one another.When I am asked to build a feedback form for a small business Web site, however, I may simply use procedural code in a single page script. I do not need enormous amounts of flexibility, I wont be building upon the initial release. I dont need to use patterns that address problems in larger systems. Instead I apply the second XP principle: Do the simplest thing that works.
When you work with a pattern catalog, the structure and process of the solution are what stick in the mind, consolidated by the code example. Before applying a pattern, though, pay close attention to the “problem” or “when to use it” section, and read up on the patterns consequences. In some contexts, the cure may be worse than the disease.
This will introduce a few of the key patterns in use at the moment, providing PHP implementations and discussing them in the broad context of PHP programming. I go into more details in my book.
The patterns described will be drawn from key catalogs including Design Patterns, Patterns of Enterprise Application Architecture, and Core J2EE Patterns. I follow the Gang of Fours categorization, dividing patterns as follows:
Patterns for Generating Objects
These patterns are concerned with the instantiation of objects. This is an important category given the principle “Code to an interface.” If we are working with abstract parent classes in our design, then we must develop strategies for instantiating objects from concrete subclasses. It is these objects that will be passed around our system.
Patterns for Organizing Objects and Classes
These patterns help us to organize the compositional relationships of our objects. More simply, these patterns show how we combine objects and classes.
These patterns describe the mechanisms by which classes and objects cooperate to achieve objectives.
We look at some patterns that describe typical Internet programming problems and solutions. Drawn largely from Patterns of Enterprise Application Architecture and Core J2EE Patterns, the patterns deal with database persistence, presentation, and application logic.
We looked at some of the principles that underpin many design patterns. We looked at the use of composition to enable object combination and recombination at runtime, resulting in more flexible structures than would be available using inheritance alone. We introduced decoupling, the practice of extracting software components from their context to make them more generally applicable. We reviewed the importance of interface as a means of decoupling clients from the details of implementation.
About the Author
Matt Zandstra has worked as a Web programmer, consultant and writer for a decade. He has been an object evangelist for most of that time. Matt is the author of SAMS Teach Yourself PHP in 24 Hours (three editions), and contributed to DHTML Unleashed. He has written articles for Linux Magazine and Zend.com. Matt works primarily with PHP, Perl and Java, building online applications. He is an engineer at Yahoo! in London. Learn more on Matt's website, getInstance.
Source of This MaterialPHP 5 Objects, Patterns, and Practice
By Matt Zandstra