Monthly Archive for April, 2010

PHP Decorator Design Pattern: Accessorizing Your Classes

Published on April 29, 2010 by Bill Sanders in Decorator. 8 Comments

decorator design pattern

Decorating an Object

Adding Just the Flourishes You Need

How would your like your concrete classes to be like an unadorned Christmas tree? When you need an ornament, you put it on. You can put on several of the same type, all different types and when they’re no longer needed, you can take them off. Your central object (class) is unchanged and you’re not processing stuff you’re not using. When you need it; you just pop it on like an ornament on a tree. Further, you can decorate different components with the same ornaments.

When would you use such a pattern? Consider setting up an order form. Each order is an object, and you decorate your order with other objects the user wants to buy. When I buy a computer, I accessorize it with with added memory, a Webcam, a USB hub and anything else that I think I need. However, the store doesn’t have to have a separate computer for every possible combination that users may want to buy. They can just have a few and let the user decorate them anyway she wants. Further, the object you want does not have to drag every option with it—just the ones the buyer wants. You can play the test case and download all of the files using the following two buttons:
Download

The Structure

To kick things off, let’s take a look at the class diagram that the Gang of Four devised. It is one of the most interesting because an abstract class is subclassed from another abstract class (among other things) as can be seen in Figure 1:

Figure 1:Decorator Class Diagram

In looking at what varies, we find that the variation is responsibilities of an object without sub-classing—in other words, use delegation. However, you can see that both the Decorator class and the Concrete Components and Decorators are all sub-classed from Abstract classes. Isn’t that inheritance instead of composition? Of all of the things that can vary in a program structure, those assigned to the Decorator still need further clarification. As you will see in the next section, the Decorator seems to even contradict its own element of variation because it double-subclasses. However, once everything is straightened out, you will find the Decorator example we use to be very simple to implement and even use in a real live work situation.
Continue reading ‘PHP Decorator Design Pattern: Accessorizing Your Classes’

Why Are PHP Design Patterns Missing Pieces?

Published on April 15, 2010 by Bill Sanders in Design Patterns. 0 Comments

Why are Participants Missing? The Case of the Missing Participants

Recently I was working on a Decorator pattern and struggling through PHP’s way of doing things. So naturally I thought why not take a look at how others have solved these same problems. The Gang of Four refer to the different classes and interfaces that make up a design pattern, as participants, and when I look at a design pattern, the first thing I do is to see how the developer handles the different participants. What I found was surprising—they left out chunks of a design pattern in their examples. Alternatively, they just did some kind of workaround that effectively made it work (run), but it was no longer a design pattern or had the advantages of a design pattern.

The Strategy with the Missing Context

The Strategy pattern decouples the algorithms from the Client by using a Context class. All of the requests for the algorithms (found in concrete Strategy classes) go through the Context to the Strategy interface and on the the implemented strategies in the form of concrete classes. However, in many of the PHP examples, they leave out the Context class and Strategy interface and go directly from an Object to concrete Strategies. In several examples, the code authors chose to ignore the interfaces and even the abstract classes and have fairly direct connections between concrete strategies and some kind of object. Figure 1 shows the kinds of UMLs that accompany these kinds of PHP design pattern implementations—if indeed they are implementations.

Figure 1: Minimalist UML

You can see clearly that the UML in Figure 1 has little in common with the class diagram we used that was an exact replica of the Strategy pattern that the Gang of Four used.

The authors of this kind of “explanation” of the Strategy pattern seem to think that the separation of the algorithms from the object is a matter of nothing more than taking the algorithms out of some object and using them independently of the main object. However, while that is an improvement on cramming everything into a single object (class), it is not a design pattern. Yes, it does add flexibility because more than one class can use the same concrete strategies. So, it’s a step away from single-class programming and even procedural programming. However, it is not a design pattern and it does not have the design pattern’s flexibility. The Context class uncouples the request from the strategy and without it, that concrete strategies are tightly linked to the “object”—whatever that may be.
Continue reading ‘Why Are PHP Design Patterns Missing Pieces?’

Private Methods in PHP

Published on April 6, 2010 by Bill Sanders in OOP and Design Pattern Principles. 4 Comments

key

Key to Private Methods

Private Methods

The other day I was adding a private method to a PHP class, and I kept getting an unusual error. After multiple debugging attempts, I did a search on the Web and found the problem. (My problem for forgetting that PHP is different.) Like class properties the keyword $this needs to be involved.

Most readers of this blog probably know this already, but I’m including this little post to remind myself as much as anyone. Essentially, when you enter a private method in a class, it must be addressed as:

$this->pvtMethod();

In an of itself, that’s no great shakes, but if you don’t know that because you’ve immigrated to PHP from some other language such as C++, Java, ActionScript 3.0 or C#, you’re going to have a big problem with design patterns. That’s because in some design patterns you’re going to want to have private methods in some of the design’s participant classes.

Why Private Methods?

Why bother with a private method? Why bother with any private accessor or visibility? That’s easy:

Private visibility encapsulates your property or method.

As objects, we want everything in our classes to be treated like an integral part. If we want to give other classes access, we use getters and setters with public accessors. For example, consider the following program example:

?View Code PHP 

ini_set("display_errors","2");
ERROR_REPORTING(E_ALL);
class PrivateProperties
{
        private $privateProp;
 
        function __construct()
        {
 
                print "From the constructor function 
";
        }
 
        public function displayMethod()
        {
                print "This is from a public method.
";
 
                $this->privateProp=$this->privateMethod();
                print $this->privateProp;
        }
 
        private function privateMethod()
        {
                return "(Private Method): This only can be called from the class itself 
";
        }     
}
$showtext=new PrivateProperties();
$showtext->displayMethod();

results:
From the constructor function
This is from a public method.
(Private Method): This only can be called from the class itself

The private method cannot be accessed directly from a call to it, but it can be launched from a public method within the same class. The function, displayMethod(), is public, but as part of the class, it can call the private methods in the same class. That’s exactly what it does.

While working with the private method, we don’t want to neglect a property with private visibility. In the same way that the $this statement is used with private methods, we also use it with private properties. As noted, this isn’t rocket science, but PHP is different from other languages, and this little reminder might come in handy when dealing with private visibility.