In een object-georiënteerd programmeren, de decorateur patroon is een patroon dat ontwerp maken het mogelijk om nieuwe / aanvullende gedrag moeten worden toegevoegd aan een bestaande klasse dynamisch.

Introduction

The decorator pattern can be used to make it possible to extend (decorate) the functionality of a class at runtime. This works by adding a new decorator class that wraps the original class. This wrapping is typically achieved by passing the original object as a parameter to the constructor of the decorator when it is created. The decorator implements the new functionality, but for functionality that is not new, the original (wrapped) class is used. The decorating class must have the same interface as the original class.

The decorator pattern is an alternative to subclassing. Subclassing adds behaviour at compile time whereas decorating can provide new behaviour at runtime.

This difference becomes most important when there are several independent ways of extending functionality. In some object-oriented programming languages, classes cannot be created at runtime, and it is typically not possible to predict what combinations of extensions will be needed at design time. This would mean that a new class would have to be made for every possible combination. By contrast, decorators are objects, created at runtime, and can be combined on a per-use basis. An example of the decorator pattern is the Java I/O Streams implementation.

Motivation

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.

Applicability

Consider viewing a webpage with a web browser. The webpage itself displays the information needed, but the web browser knows nothing about the content. It is likely that the webpage doesn’t fit in the entire browser area and a scrollbar is required to show the information. The web browser doesn’t need to assume that all webpages will require a scrollbar and it certainly should never assume a scrollbar is never needed. Browsers will typically display the scrollbar only if it is necessary and hide it if it is unnecessary. In this case, the scrollbar is the “decoration” to the webpage. It takes care of whether it should be displayed dynamically as opposed to statically forcing the webpage display to be a subclass of the scrollbar display. Thus, it is up to the scrollbar to decide whether it should display itself (instead of trying to force that responsibility on the webpage or on the external parts of the web browser).

// the Window interface
interface Window {
    public void draw(); // draws the Window
    public String getDescription(); // returns a description of the Window
}

// implementation of a simple Window without any scrollbars
class SimpleWindow implements Window {
    public void draw() {
       // draw window
    }

    public String getDescription() {
       return "simple window";
    }
}

// abstract decorator class - note that it implements Window
abstract class WindowDecorator implements Window {
    protected Window decoratedWindow; // the Window being decorated

    public WindowDecorator (Window decoratedWindow) {
       this.decoratedWindow = decoratedWindow;
    }
}

// the first concrete decorator which adds vertical scrollbar functionality
class VerticalScrollBarDecorator extends WindowDecorator {
    public VerticalScrollBarDecorator (Window decoratedWindow) {
       super(decoratedWindow);
    }

    public void draw() {
       drawVerticalScrollBar();
       decoratedWindow.draw();
    }

    private void drawVerticalScrollBar() {
       // draw the vertical scrollbar
    }

    public String getDescription() {
       return decoratedWindow.getDescription() + ", including vertical scrollbars";
    }
}

// the second concrete decorator which adds horizontal scrollbar functionality
class HorizontalScrollBarDecorator extends WindowDecorator {
    public HorizontalScrollBarDecorator (Window decoratedWindow) {
       super(decoratedWindow);
    }

    public void draw() {
       drawHorizontalScrollBar();
       decoratedWindow.draw();
    }

    private void drawHorizontalScrollBar() {
       // draw the horizontal scrollbar
    }

    public String getDescription() {
       return decoratedWindow.getDescription() + ", including horizontal scrollbars";
    }
}

Comments are closed.