I just recently really truly groked dependency injection and the wonder of the Decorator design pattern and am using it all over the place.
As wonderful as it is however, one thing that I've been having difficulty with is naming my decorator classes so I would just like to know what others do. Do you always append the word Decorator? Do you incorporate the name of the interface its decorating? Do they get their own namespace?
What do you guys do?
Generally where the pattern is encapsulated in an object (vs. a collection of objects) then it's clearer and easier to include the pattern name in the class, in this case using Decorator as a suffix. This work well for proxies, decorators, factories, adapters etc.. but does not work for other patterns where a group of objects is needed in the implementation of the pattern like a bridge (i.e. what object would appropraitely take the -bridge suffix?)
I avoid using design pattern names. I think this belongs in documentation if anywhere. Name the decorator class/function after what it does or represents. The fact that it decorates or bridges or links or proxies or re-represents is of little consequence.
Every time you name a string, do you add a String suffix? Sounds like hgrnNotation to me, and that is something I try and avoid.
Call it what it does.
I have a bunch of decorators for an IPrinter interface. They're called:
These chaps both inherit from PrintDecorator, so if someone peeks beneath the covers they can see whats going on.
Take an example from the Java API's IO Framework. It uses the decorator pattern extensively but the names of the classes do not reflect this. For instance a BufferedReader may decorate a FileReader But they are named after their function - Readers.
Adding decorator to the name would lead to further problems if you also incorporate other patterns involving the same classes as is frequently the case. You might end up with a class named MyDecoratorStrategyComponent.