Monthly Archive for February, 2010

Design Pattern Principles for PHP: Program to an Interface; not an implementation

Published on February 27, 2010 by Bill Sanders in OOP and Design Pattern Principles. 5 Comments

Principal's Principle

Principles in Design Patterns and OOP

One of the things we’ve learned from our discussions of design patterns and OOP is that very few want to discuss principles. Put in a piece of code and there’ll be plenty of comments on how to tweak the code, but when we write about principles, we only get a few comments—if we get any at all.

We wish the opposite were true, and readers would gather up some code to illustrate their conception of a principle at work. We’re hoping that because PHP is a dynamic language (aka: weakly typed) there’ll be plenty of discussion of principles that were apparently created for strongly typed languages like Java, C# and ActionScript 3.0. In order to signal that a post is about a principle we’ve included an image of our favorite principal, Principal Seymore Skinner of the Simpsons. When you see Skinner, think OOP/Design Pattern Principle and I’ve got something to say about that!

The first principle of design patterns is,

Program to an interface, not an implementation

Simply put, the Gang of Four urges programmers to declare variables only to abstract classes and interfaces and not concrete implementations. You never want to type your instance as a concrete class derived from an interface or abstract class—only to the interface.

For any red-blooded PHP programmer, this may sound heretical because one does not declare types with either variables or functions. (Type hinting may do something like that, but more on it later.) However, after only a little reflection, we realize that PHP can indeed program to the interface by declaring variables (properties) and functions (methods) through classes that implement interfaces or extend abstract classes.
Continue reading ‘Design Pattern Principles for PHP: Program to an Interface; not an implementation’

PHP Chain of Responsibility : Making a Selection

Published on February 25, 2010 by Bill Sanders in Chain of Responsibility. 2 Comments

The Chain of Responsibility (CoR) design pattern is used when you need a request handled by the most appropriate object for the request. You don’t need to worry about which object handles the request or even if they’ll handle it the same all the time. For example, suppose you have a constantly changing marketplace and the specs of your request change as well. Rather than building an application that links a specific request to a specific request handler the CoR pattern decouples the two so that when a request is sent, all you know is that the most appropriate object will handle it. Our department buys USB drives in bulk from China. In the request for the drives I put in a set of criteria and send the request to my Chinese buyer. He is instructed to get the lowest price for the drives as long as they meet the specs in the required bulk. Now I don’t know which manufacturer will win the contract (which object will handle the request), but since I trust my agent in China, I am confident he’ll get the best price even though the price will vary depending on everything from the dollar’s exchange rate with China to the availability of USB drives. Because so many variables change, I need the flexibility that changes with both the request and the request handler. That’s something like the way the CoR design pattern works—it takes a request and finds the most appropriate way to handle it.

Play the application to see what happens (not much) and download the code using the following buttons:

Chain of Responsibility Overview

Because looking at a Class Diagram is useful for seeing the larger context of the design pattern, we’ll look at it first and then go about describing its features.

Figure 1: Chain of Responsibility Class Diagram

This looks fairly simple, and at the basic level it really is. Like some of the other design patterns, the Client is part of the pattern, and so it’s integral. At the center of the pattern is the Handler interface. For the time being, think of the interface as an abstract class because that is what is used in the initial example. The abstract class includes a function for setting successors in a chain and another to handle a request. Finally, the ConcreteHandler classes represent the specific and different classes that handle requests. Generally speaking, an application would include several ConcreteHandler classes, and each is set up in a chain to deal with requests where appropriate.
Continue reading ‘PHP Chain of Responsibility : Making a Selection’

PHP Design Patterns: An Introduction

Published on February 23, 2010 by Bill Sanders in Introduction to Design Patterns. 2 Comments

Design Patterns are about Relations Between Participants


What Are Design Patterns?

Design patterns are a way to create excellent OOP programs where update and changes can be made without having to rebuild your site from scratch. In many respects, they are the implementation of OOP principles into several different patterns for common uses. They are not templates but rather strategies for solving common programming problems with OOP.

The Pleasure of Doing Something Well

With PHP 5 (or some build of PHP 5) came a host of OOP structures including abstract classes, interfaces, class and method accessors and other OOP elements that moved PHP closer to an OOP language. Do you need OOP for writing effective and practical code in PHP? No. Will learning OOP make you a better programmer? Yes. Design patterns will make you a superior programmer.

If that doesn’t answer your question of Why bother with OOP or Design Patterns?; then this blog probably isn’t for you—at least now now. If you do derive pleasure in doing something well, all you need are a few OOP and Design Pattern principles and lots of patience with understanding advanced programming concepts. Here are a few OOP principles:

  • A class should only have a single responsibility
  • Strive for loosely coupled objects (classes)
  • Favor composition over inheritance
  • Subclass from interfaces and abstract classes

We’ll be discussing those and other OOP/Design Pattern principles with examples in PHP. The principles apply to all languages, and so if you’re familiar with them from one programming language you’ll find that they apply to PHP as well. The syntax may be different but the principles remain the same.
Continue reading ‘PHP Design Patterns: An Introduction’