Should a decorator always extend the decorated in Decorator pattern

[Kumar Raja]

Hi All,

As per the wikipedia, the decorator pattern is defined as
"The decorator pattern can be used to extend (decorate) the functionality of a certain object statically, or in some cases at run-time, independently of other instances of the same class, provided some groundwork is done at design time. This is achieved by designing a new decorator class that wraps the original class. This wrapping could be achieved by the following sequence of steps:

1.Subclass the original "Component" class into a "Decorator" class (see UML diagram);
2.In the Decorator class, add a Component pointer as a field;
3.Pass a Component to the Decorator constructor to initialize the Component pointer;
4.In the Decorator class, redirect all "Component" methods to the "Component" pointer; and
5.In the ConcreteDecorator class, override any Component method(s) whose behavior needs to be modified.
"

It means the Decorator should actually extend the component that needs to be decorated.

My question is, is this requirement always rigid to be called as a Decorator pattern.

The reason I'm asking this question is, I have a bean class with lot of setters and getters and I do not have access to change the code. However, I wanted to print the bean's data in a particular format.

My approach is as follows

     class Bean{

       //lots of setters and getters
       public String toString(){
      }

So basically this bean does nothing (no business functionality exists). We can assume that this is just a container of some data and also has some basic toString() method which prints the data. However, I want to have the data printed in a very particular way based on some business rules.

Now I'm thinking of implementing something like this

   public interface Decorator{
     
      public String decorate();
  }

  pubilc class CustomDecorator implements Decorator{

       private Bean mybean;
       CustomDecorator(Bean mybean){
         
          this.mybean = mybean;
      }

      public String decorate(){

             //decorate mybean based on some rules
     }
 }

 pubilc class AnotherDecorator implements Decorator{

       private Bean mybean;
       CustomDecorator(Bean mybean){
         
          this.mybean = mybean;
      }

      public String decorate(){

             //decorate mybean based on some other rules
     }
 }

    class Client{

        public static void main(String[] args){

           Bean mybean = constructBean();
           Decorator decorator1 = new CustomDecorator(mybean);
           Decorator decorator2 = new AnotherDecorator(mybean);

           decorator1.decorate();
           decorator2.decorate();
        }
    }

Can the above approach be considered as Decorator pattern, as this also supplying runtime behavior to Bean class ? If this is not a decorator, is this any other pattern ?

Thanks

[Jeff Verdegan]

Kumar Raja wrote:
It means the Decorator should actually extend the component that needs to be decorated.

No. In fact I would think it would be less common to do it that way. What is more common (in my experience--your mileage may vary) is for the decorator and decorated to both inherit from some common abstract type, whether both extending an abstract class or both implementing an interface.

Look at the various decorator Streams, Readers, and Writers in java.io for examples.

Also Collections.synchronizedXxx() and unmodifiableXxx().

[Kumar Raja]

Thank you Jeff,

But is the approach I followed can be considered as a type of decorator. Because, they both do not relate to each other in any way.

[Steve Luke]

Kumar Raja wrote:But is the approach I followed can be considered as a type of decorator.

No. The point of the decorator pattern is that the decorator instance appears and acts just like the decorated instance, except in the point behavior modification. That is, if you have a Bean, and then you decorate the Bean so that it has a different toString() method, then you should be able to use the decorated Bean as if it were a Bean - pass it to all the classes which have Bean parameters, call all the Bean methods from it, etc... The code that uses the Bean would not know (or care) that it has a decorated Bean. The only difference would be the behavior of the modified method(s).

Since your example code, the Decorators do not extend Bean, so if you have code which takes a Bean, it can not take a Decorator. You also have a method in the Decorator which is not present in the Bean (decorate) which means code which does not know about the Decorator (and does not know that the Bean it is using is a Decorator) can not use that method.

The Wikipedia article, in the very next two lines after what you quoted says:

This pattern is designed so that multiple decorators can be stacked on top of each other, each time adding a new functionality ...
Note that decorators and the original class object share a common set of features.

Since your Decorators only act on Beans, and your Decorators are not Beans, you can not stack one on top of another. Since they do not implement/extend a base class they do not share a common set of features.

(note regarding what Jeff said, which is the same as the Wikipedia article draws and details the pattern: The 'common set of features' is usually abstracted out to a parent type inherited by both the decorator and concrete base class. )