James Carman schrieb:
>
> This pattern (replacing the implementation of specific methods) is not
> supported "out of the box" by Proxy, but perhaps it should be? I
> wonder how common it is that you'd want to replace the implementation
> of certain methods and you wouldn't just go ahead and extend the class
> and override the methods yourself? Now, if the class is final, you
> can't extend it, but then again you wouldn't be able to proxy it
> anyway unless of course you're trying to replace the implementation of
> an implemented interface's method.
>
This is getting a little off-topic, but...
The decorator pattern is hugely useful. In particular, you can apply a
decorator to an existing object (eg something returned by a library),
which you cannot achieve by subclassing something. Even when it is your
own code that is creating the actual object instance, a decorator is
sometimes a more elegant approach than subclassing anyway.
Having commons-proxy provide a way to proxy just specific methods would
be nice, although not critical IMO. Proxying a specific method or
methods can of course be built on top of a generic proxy API simply by:
if (method.name == "foo") {
// do something
} else {
method.invoke(proxy, args); // just forward the call on to the
original object
}
but this is a little ugly.
Having commons-proxy support running AOP Advices for specific methods
while passing the others through automatically would be nice. However
the standard "pointcut" language for specifying which methods to match
is rather ugly and complex. And turning commons-proxy into a full AOP
library supporting the org.aopalliance.aop.* APIs
(http://aopalliance.sourceforge.net/) would be a big job. I presume
you're aware that springframework.org includes extensive AOP support
based on the aopalliance APIs?
Regards, Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
