commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Carman" <ja...@carmanconsulting.com>
Subject Re: [configuration] Interface vs class
Date Wed, 05 Nov 2008 10:11:43 GMT
On Wed, Nov 5, 2008 at 4:42 AM, Simon Kitching <skitching@apache.org> wrote:
> The standard JDK interface-based proxying would certainly become more
> useful.
>

I meant changing Proxy's ProxyFactory from a class to an interface (or
perhaps introducing the IProxyFactory interface and leaving
ProxyFactory as the default implementation, based on JDK proxies).

> One issue that the above doesn't deal with is applying the decorator
> pattern to such interfaces.
>
> If someone wants to decorate an existing implementation by intercepting
> one or more methods, then they certainly can do so by using dynamic
> proxying (via commons-proxy or similar), as the type is now an interface.
>

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.

> If someone wants to hand-write a decorator class, though, then they are
> in trouble as the abstract base class won't help there and the project
> reserves the right to extend the interface. I suppose the project could
> *also* provide an abstract "delegator" class for each interface that
> simply delegates all methods. That's then *two* abstract classes for
> each interface though, which is getting a little clumsy. Or we could
> simply say "get with the modern world and use a dynamic proxy"...
>
> Regards,
> Simon
>
> --
> -- Emails in "mixed" posting style will be ignored
> -- (http://en.wikipedia.org/wiki/Posting_style)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message