Wrapper/Proxy pattern

Question

Hi,
We�re in the process of updating one of our APIs, which contains lots of interfaces (backed by heavyweight implementations - the java.sql package is a good comparison). I want to help vendors to wrap our existing implementations so that they can add extra functionality without having to re-implement all the backend workings by providing a "wrappers" package, which simply passes (unwrapped) arguments to the underlying implementations, and wraps returned heavyweights coming back up, allowing the vendors to add small amounts of functionality where needed.
// interfaces, could be heavyweight or wrappers..
interface Foo {
    Bar getBar(Hee theHee);
interface Bar {
   Foo getFoo();
// wrappers
class FooWrapper implements Foo {
     private final Foo myWrapped;
     public FooWrapper(Foo theWrapped) {
          this.myWrapped = theWrapped;
     public Bar getBar(Hee theHee) {
          return new BarWrapper(this.myWrapped.getBar(theHee));
class BarWrapper implements Bar {
     private final Bar myWrapped;
     public BarWrapper(Bar theWrapped) {
          this.myWrapped = theWrapped;
     public Foo getFoo() {
          return new FooWrapper(this.myWrapped.getFoo());
}The first issue I had with this was the calling new XxxWrapper is patently bum, as it means that the methods have to be overridden anyway to stop the "default" XxxWrappers from being returned. This, in my opinion, is easily solved by using a WrapperFactory, which can be passed in during construction of the wrapper, and called where needed to allow the user to supply there own wrapper implementations.
The second issue involves "unwrapping" which I am unsure as to the best way forward. In the, as yet undisclosed, "Hee" we should really have unwrapped it before passing it to the underlying Foo, otherwise it will still be the wrapped version of the Hee, (assuming) HeeWrapper. This is where the questions arise.
-What happens if it's not a HeeWrapper? My Initial thoughts are throw an exception, as, assuming it's come from our provider/factory, it should have been wrapped by us before the user could have gotten hold of it. Unless of course the WrapperFactory isn't returning HeeWrappers for some reason?
-What�s the best way to unwrap it? Again, initially I thought of adding an unwrapXxx to the WrapperFactory and let the user deal with it, though this seems to add too many methods. I also thought about WrapperFactory.unwrap(Object) letting the provider unwrap it generically and then casting the results? I avoided adding a Hee.unwrap() method in case it could lead to mistakenly unwrapping other providers (who are also using the wrappers package) implementations, though this may be a bit anal, but I�m sure I could abuse it (and therefore others no doubt could), so I want to avoid it.
-What happens if the Hee originates from the underlying implementation, say via an event? Delegate the wrapping of that Hee to the factory again? Should the default factory cache the results to allow the same wrapper to be returned each time, or just create a new one?
Has anyone done anything like this, or have any obvious solutions that I've missed, or just some preference?

Answer 1

So what you want to do with wrappers is beyond me.
Why do you not want to use abstract classes? What problem do you think is going unsolved in that case?I might be misunderstanding the problem but it's been while since prefer "composition to extension" became a mantra.
Suppose you have a type Foo. And you have behaviors Up and Down you wish to implement:
UpFoo
DownFoo
But wait, what if up and down aren't mutually exclusive (OK I could have chosen better names here.)
UpDownFoo
Great. Now here come Charm and Strange. So let's add:
CharmFoo
StrangeFoo
Now the combos:
UpCharmFoo
DownCharmFoo
UpStrangeFoo
DownStrangeFoo
UpDownCharmFoo
UpDownStrangeFoo
CharmStrangeFoo
UpCharmStrangeFoo
DownCharmStrangeFoo
UpDownCharmStrangeFoo
Whew. That was a lot of classes to write. I hope I didn't miss any. Uh oh, here come Top and Bottom...
I'm not going to type these out. Suffice it to say that this is an unsustainable approach. A good example of this approach is the Collections class which provides A synchronized wrapper and a unmodifiable wrapper so that we don't end up with all the permutations with all the map implementations.
This is usually called the Decorator pattern and it has been considered before. It's in the GoF.