Add some helpful syntatic sugar for the decorator pattern (i.e. composition not inheritance)
interface IWindow {
public void Draw();
public void Close();
... more methods ...
}
sealed class SimpleWindow: IWindow {
public void Draw() {/* draw window */}
... more methods ...
}
//extending this to add a scoll bar
sealed class ScrollBarDecorator : IWindow {
private IWindow _component; //component class that has the basic implementation
public VerticalScrollBarDecorator (IWindow decoratedWindow) {
_component = decoratedWindow;
}
//"override" the behaviour we want to change/extend (one line)
public void IWindow.Draw() {
DrawScrollBar();
_component.Draw();
}
//then type lots (potentially pages) of boilerplate code to forward the rest of the methods straight to the underlying component
public void IWindow.Close() {
_component.Close();
}
... more methods ...
}
Unpleasant. Most people won't bother or will find any way to avoid this (i.e. damaging their class structures, twisting their code, bloating type hierarchies) - whereas, if we had a bit of syntatic sugar for this:
sealed class ScrollBarDecorator : IWindow {
//note the new keyword "decorates"
decorates private IWindow _component;
public VerticalScrollBarDecorator (IWindow decoratedWindow) {
_component = decoratedWindow;
}
//"override" just the behaviour we want to change/extend
public void IWindow.Draw() {
DrawScrollBar();
_component.Draw();
}
}
Finished. The boiler plate code to implement IWindow, delegating all the calls to _component would be implied/generated by the compiler. Far more coders would use this pattern if it were this simple to type.
