From Patterns For PHP
Note: This is a draft article dated 14 September 2006. The supplied code has not been tested.
Altering the behaviour of objects is a tricky business. In many cases you do not wish to alter the original object but rather tack on additional or modified behaviours. The easiest way to achieve this is using inheritance. Creating a series of subclasses allows a programmer to add additional methods and properties or alter those which already exist in the parent class. Unfortunately, as other Design Patterns often point out, inheritance can be a path full of pitfalls and traps for the unwary. The more layers exist in a class hierarchy, the more cumbersome and difficult to manage the whole structure becomes.
If we decide to set a goal of maintaining the original class as is and of disallowing any further inheritance, we immediately gain some measure of control. By preventing further inheritance we have a smaller discrete unit perfect for reuse in other projects minus the specific modifications current circumstances might require. To extend the original class and add new or modified behaviour to it we can use the Decorator Pattern.
The Decorator Pattern creates a separate class family which adds extended behaviour to an existing class while leaving the existing class unchanged. As the class is ported for reuse, we can transparently add new Decorators specific to each new application as we see fit. Additionally, since the Decorator classes are in a separate hierarchy they have a variable type which is distinct from the original class, i.e. we can tell if a class is a Decorator.
Of course the Decorator Pattern is not a silver bullet. Inheritance remains the simplest option and the Decorator Pattern is not suitable for all scenarios. However it remains an extremely useful option and is one of the more popular Design Patterns programmers are intimately familiar with, especially in web application development.
Definition: The Decorator Pattern represents the process of creating a new class hierarchy which adds new or modified behaviour to an existing class without modifying the existing class from its original state.
Description of the Problem
Let's introduce an example of a situation which lends itself to improvement through the application of the Design Pattern. During the development of an application we discover a need to store data to a file. For simplicity, the data is a simple string. A generic String_Writer class is ported from a pre-existing project. The class simply accepts a string and writes it to a specified file, storing the data in a property access by a public getter/setter pair. The class is generic in that it just stores strings. Outputting and additional formatting for display is not handled by the basic class. As a result it is decided to extend the String_Writer class behaviour to add formatting options for output and to add an output method.
Inheritance has been ruled out as an option for a number of reasons. First of all, there can be any number of formatting options. Adding each option to the original String_Writer class through inheritance could become complex, resulting in a class hierarchy many levels deep. Changes to any class high in the hierarchy might require modifying all subsequent child classes for the change in interface or properties in the higher level parent - a time-consuming task.
The Decorator Pattern on the other hand avoids multi-level inheritance.
Implementing the Decorator Pattern in PHP5
The basic String_Writer class is extremely simple:
The String_Writer class should be fairly simple to follow. We instantiate the class passing the path to the relevant log file in the constructor parameter. To store a new string in the file, we call setString(), followed by store(). Each store appends a newline to the data using the PHP_EOL constant to be agreeable for Unix, Mac or Windows systems.
In order to format the stored string for output without resorting to inheritance, we create a new class hierarchy. It's structure will be simple, a parent class and any number of specific child classes. We will call the parent class String_Formatter. The Formatter and its children implement the Decorator Pattern, i.e. they extend the functionality of the existing class, String_Writer, by supplying new formatting and output options. The String_Writer class is left unchanged.
The String_Formatter class is as follows:
The String_Formatter class is likewise simple. The additional behaviour is simply the output() method. By default this simply returns the value of the string held by the String_Writer object. No formatting is performed by default.
To make things interesting, we extend our basic String_Formatter class with a selection of child classes which format the output string. Here's three examples: Uppercase, Reverse, and Escape.
Each individual subclass performs a different formatting function. Of course using just one type of formatting is limited. Rather each subclass of String_Formatter accepts other related classes of the same type as arguments to its constructor. By linking all the decorators to each other, it is possible to perform specific formatting by calling each Decorator's formatting method.
An example usage:
The Decorator Pattern is not suitable for all possible situations. If the number of Decorator options is limited and it does not add significantly to the number of hierarchy levels then inheritance is possibly a better option. In general however, class hierarchies should be fairly shallow. If a hierachy of classes is more than three levels deep then you should consider refactoring some of the additional elements using the Decorator Pattern or certain other Patterns instead. A deep class hierarchy can easily become a morass of dependencies where changes have knock on effects across numerous inheriting classes. Avoiding such maintenance black holes should be a priority.
In this article we have briefly examined a simple implementation of the Decorator Pattern. This pattern is an alternative to persistent subclassing in order to add new or modified behaviour to the ultimate parent class. Rather than using inheritance, one can build a separate class hierarchy of the behaviour required and apply the methods of the new classes to the original class. An essential feature of the Decorator Pattern is that the original class does not require any additional modification in order to apply the Pattern.