PHP Objects, Patterns and Practice (3rd edition)

CHAPTER 10 ■ PATTERNS FOR FLEXIBLE OBJECT PROGRAMMING

Figure 10–5. The Decorator pattern

This model is very extensible. You can add new decorators and components very easily. With lots of
decorators you can build very flexible structures at runtime. The component class, Plains in this case,
can be significantly modified in very many ways without the need to build the totality of the
modifications into the class hierarchy. In plain English, this means you can have a polluted Plains object
that has diamonds without having to create a PollutedDiamondPlains object.
The Decorator pattern builds up pipelines that are very useful for creating filters. The Java IO
package makes great use of decorator classes. The client coder can combine decorator objects with core
components to add filtering, buffering, compression, and so on to core methods like read(). My web
request example can also be developed into a configurable pipeline. Here’s a simple implementation
that uses the Decorator pattern:

class RequestHelper{}

abstract class ProcessRequest {
abstract function process( RequestHelper $req );
}

class MainProcess extends ProcessRequest {
function process( RequestHelper $req ) {
print CLASS.": doing something useful with request\n";
}
}

abstract class DecorateProcess extends ProcessRequest {
protected $processrequest;
function __construct( ProcessRequest $pr ) {
$this->processrequest = $pr;
}
}

As before, we define an abstract super class (ProcessRequest), a concrete component (MainProcess),
and an abstract decorator (DecorateProcess). MainProcess::process() does nothing but report that it has
been called. DecorateProcess stores a ProcessRequest object on behalf of its children. Here are some
simple concrete decorator classes: