Computer Software Talk

Giovanni Azua · Guest

hi,

I was working on providing a componentized reusable implementation of the
Decorator pattern and came out with something that works as illustrated in
the example below, for easier reference I used the same example as GoF:

http://perfectjpattern.svn.sourceforge.net/viewvc/perfectjpattern/trunk/perfectjpattern-examples/src/main/java/perfectjpattern/core/structural/decorator/Example.java?view=markup

My question is => how inconvenient is to have a decorator that attaches
additional methods and that does not have the decorated type directly
implemented/accessible but under one level of indirection e.g.

IVisualComponent
(+focus)
(+hide)
^ ^
| |
| |
TextView |
|
-----------------------------
| |
ScrollDecorator |
(+scrollTo) |
BorderDecorator

The common usage for ScrollDecorator would be:
*******************************************************
ScrollDecorator myDecorator = new ScrollDecorator(new TextView());

// calls decorator's specific additional method
myDecorator.scrollTo();

// calls decorated component's interface
myDecorator.focus();
myDecorator.hide();
******************************************************

However in perfectjpattern's current componentized implementation the way
would be:

******************************************************
ScrollDecorator myDecorator = new ScrollDecorator(new TextView());

// calls decorator's specific additional method
myDecorator.scrollTo();

//
// IVisualComponent is not directly implemented by ScrollDecorator.
// But getting a Component type view of it. Note that even though
// you call here "getComponent()" what you actually get is the (decorated)
// Component interface type view implemented by ScrollDecorator
// and not the TextView instance
//
myDecorator.getComponent().focus();
myDecorator.getComponent().hide();
******************************************************

In any case I would asume that it is more commonly used the variation of the
Decorator that only redefines functionality rather than adding i.e.
reusability, therefore continuing the example above would be:

// note again getComponent() means get me the Component type view of the
// Decorator (it is decorated)
//
IVisualComponent myComponent = new ScrollDecorator(new
TextView()).getComponent();

If you are wondering what the main advantage of the partially componentized
perfectjpattern's Decorator is, here is the answer:

- perfectjpattern offers a base class AbstractDecorator<C> from which you
extend and specify which type you would like to decorate and implementation
for exactly and only the methods you want to decorate e.g.
http://perfectjpattern.svn.sourceforge.net/viewvc/perfectjpattern/trunk/perfectjpattern-examples/src/main/java/perfectjpattern/core/structural/decorator/ScrollDecorator.java?view=markup

- you either define your additional methods e.g. scrollTo() or redefine some
of the methods of the underlying component without having to provide
implementation for the full Component interface e.g. IVisualComponent but
only implement those relevant methods you want to decorate.

Advantage: Having many decorator implementations is more maintainable and
reusable because adding more functionality/methods in the Component
interface will not require existing Decorators to continuously be
modified/adapted to provide empty implementations.

Disadvantage: Since the Decorator does not directly implement the Component
interface, changing the component interface might lead to bugs i.e. leaks
where intended redefining methods might end up being bypassed. However a
valid solution would be fine graining the Component interface into many
smaller interfaces and the decorator hard (type) implementing only those
relevant while still decorating the full Component interface.

Thanks in advance,
regards,
Giovanni