8

This question regards the usage of the Decorator pattern to add little functionality to objects of large classes.

Following the classic Decorator pattern, please consider the following class structure:

enter image description here

For example, imagine this happens inside a game. Instances of ConcreteCharacterDecorator are meant to add little functionality to the ConcreteCharacter they are 'wrapping'.

For instance, methodA() returns an int value representing the damage the character inflicts on enemies. The ConcreteCharacterDecorator simply adds to this value. Thus, it only needs to add code to methodA(). The functionality of methodB() stays the same.

ConcreteCharacterDecorator will look like this:

class ConcreteCharacterDecorator extends AbstractCharacterDecorator{

    ConcreteCharacter character;

    public ConcreteCharacterDecorator(ConcreteCharacter character){
        this.character = character;
    }

    public int methodA(){
        return 10 + character.methodA();
    }

    public int methodB(){
        character.methodB(); // simply delegate to the wrapped object.
    }

}

This is no problem with small classes containing two methods.

But what if AbstractCharacter defined 15 methods? ConcreteCharacterDecorator would have to implement all of them, even though it's only meant to add little functionality.

I will end up with a class containing one method that adds a little functionality, and another 14 methods that simply delegate to the inner object.

It would look like so:

class ConcreteCharacterDecorator extends AbstractCharacterDecorator{

    ConcreteCharacter character;

    public ConcreteCharacterDecorator(ConcreteCharacter character){
        this.character = character;
    }

    public int methodA(){
        return 10 + character.methodA();
    }

    public int methodB(){
        character.methodB(); // simply delegate to the wrapped object.
    }
    public int methodC(){
        character.methodC(); // simply delegate to the wrapped object.
    }
    public int methodD(){
        character.methodD(); // simply delegate to the wrapped object.
    }
    public int methodE(){
        character.methodE(); // simply delegate to the wrapped object.
    }
    public int methodF(){
        character.methodF(); // simply delegate to the wrapped object.
    }
    public int methodG(){
        character.methodG(); // simply delegate to the wrapped object.
    }
    public int methodH(){
        character.methodH(); // simply delegate to the wrapped object.
    }
    public int methodI(){
        character.methodI(); // simply delegate to the wrapped object.
    }
    public int methodJ(){
        character.methodJ(); // simply delegate to the wrapped object.
    }
    public int methodK(){
        character.methodK(); // simply delegate to the wrapped object.
    }
    public int methodL(){
        character.methodL(); // simply delegate to the wrapped object.
    }
    public int methodM(){
        character.methodM(); // simply delegate to the wrapped object.
    }
    public int methodN(){
        character.methodN(); // simply delegate to the wrapped object.
    }
    public int methodO(){
        character.methodO(); // simply delegate to the wrapped object.
    }

}

Obviously, very ugly.

I'm probably not the first to encounter this problem with the Decorator. How can I avoid this?

6

Quick and easy: AbstractCharacterDelegator does not have abstract functions, but virtual instead. By default, they pass through to the wrapped character and can be overridden. Then you inherit and only override the few you want.

This sort of thing isn't particularly useful unless you do quite a bit of decoration and your common interface is particularly wide. That shouldn't be too common. And this approach might not be by the letter a decorator, but it uses the concept and would be well understood to be a decorator by programmers that know the pattern.

6
  • So you're suggesting to simply - in Java - make the methods in AbstractCharacterDelegator 'regular' (since all 'regular' methods in Java are virtual by default - meaning they can be overridden by inheriting subclasses)? And have their implementation simply delegate to the inner object - and if I want to change that, simply override them? – Aviv Cohn Mar 22 '14 at 10:47
  • If so, that means that indeed I'll have to use abstract classes, and not interfaces, since interfaces don't allow for implementation in the methods. So I'll have cleaner code, but no 'multiple inheritance' with interfaces. Which one is more important? – Aviv Cohn Mar 22 '14 at 10:48
  • @Prog Yes, that's what he's saying. It doesn't rule out using an interface. Going back to the UML diagram, you can turn AbstractCharacter into an interface. The rest remains much the same - ConcreteCharacter and AbstractCharacterDecorator implement the interface instead of subclassing. Everything should just work. Although they probably don't need to extend anything else, your decorators aren't locked into subclassing AbstractCharacterDecorator since they could always do the delegation the old-fashioned way if they ever needed to extend a different class for some reason. – Doval Mar 22 '14 at 11:33
  • @Doval So basically, the best approach would be to have AbstractCharacter an interface, and everything else concrete or abstract classes. This would allow for clean code, like Telastyn said, but for more flexibility the using all abstract classes. Right? – Aviv Cohn Mar 22 '14 at 11:37
  • 1
    @Prog Yes, that about sums it up. – Doval Mar 22 '14 at 11:47
3

If AbstractCharacter has 15 methods, it probably needs to be broken down into smaller classes. That aside, there's not much else you can do without the language providing some sort of special syntax support for delegation. Simply leave a comment where all the delegation starts so the reader knows he need not look any further down. As for writing all the forwarding methods, your IDE can help there.

That aside, it's my opinion that Decorator works best with interfaces. You generally either want to limit your abstraction to a finite (possibly 0) number of subclasses or go all the way with an interface. Unlimited inheritance has all of the drawbacks of interfaces (you could be passed an incorrect implementation) but you don't get full flexibility (you can only subclass one thing.) Worse yet, it opens you up to the Fragile Base Class Problem and it's not as flexible as composition (you make SubclassA and SubclassB, but then can't inherit from both to make SubclassAB with features of both). So I find being forced into an inheritance tree just to support decoration to be a kludge.

2
  • +1 for stating the cohesion problem (too many responsibilities is 15 methods) and using interfaces. – Fuhrmanator Mar 22 '14 at 20:34
  • Sometimes it can not be broken down into smaller classes, let's say a file system class. – Vicente Bolea Jun 20 '16 at 17:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.