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:
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?
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
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