Mark’s Site

The decorator pattern allows us to extend (decorate) the functionality of a class at runtime (wikipedia).

I was largely self taught in programming, so this description sounded just like classes, subclasses, and the whole concept of inheritance, but this is a different concept (related, but different). A good example I found made this easier to understand, so I thought it relevant to share the ‘easy to learn’ stuff around

The decorator patterns works by creating a ‘decorator’ class that wraps the original class. This effect is achieved by passing the original object as a parameter to the constructor of the decorator class. You specify any extended (or new) functionality in the decorator class, and any original class functionality can be called as usual (don’t worry, there’s a good example to follow soon).

So straight away I’m asking:

“Why the hell would I want to do that when I can use inheritance and have a neat class/subclass solution that I am more comfortable with?”

and

“What is the difference between the decorator pattern and standard inheritance?”

Well, inheritance happens at compile time, whereas decorating provides the original classes with the additional (decorated) functionality at runtime.

Wow, that sounds real important. Who cares! I use PHP, compile and runtime mean bugger all to me. Give me a reason why I would use this method! It took this example to finally get the message across to me

Real world example

“As an example, consider a window in a windowing system. To allow scrolling of the window’s contents, we may wish to add horizontal or vertical scrollbars to it, as appropriate. Assume windows are represented by instances of the Window class, and assume this class has no functionality for adding scrollbars. We could create a subclass ScrollingWindow that provides them, or we could create a ScrollingWindowDecorator that merely adds this functionality to existing Window objects. At this point, either solution would be fine.

Now let’s assume we also wish the option to add borders to our windows. Again, our original Window class has no support. The ScrollingWindow subclass now poses a problem, because it has effectively created a new kind of window. If we wish to add border support to all windows, we must create subclasses WindowWithBorder and ScrollingWindowWithBorder. Obviously, this problem gets worse with every new feature to be added. For the decorator solution, we need merely create a new BorderedWindowDecorator—at runtime, we can decorate existing windows with the ScrollingWindowDecorator or the BorderedWindowDecorator or both, as we see fit.

Another good example of where a decorator can be desired is when there is a need to restrict access to an object’s properties or methods according to some set of rules or perhaps several parallel sets of rules (different user credentials, etc). In this case instead of implementing the access control in the original object it is left unchanged and unaware of any restrictions on its use, and it is wrapped in an access control decorator object, which can then serve only the permitted subset of the original object’s interface.” (wikipedia)