Personally, my first reaction is that this is missing the point.
What /we/ are trying to achieve is a clean distinction between an
object and its collaborators, so cutting a slice through another
object where we use some bits but not others doesn't help with that.
The only motivation for us to do this would be because we're working
with a third-party library we can't change. In which case, we'd
introduce an interface to collaborate with and a thin veneer to
implement that interface in terms of the external class. Otherwise,
we'd break up the external object, or at least have it implement an
interface that describes the relationship we need.
S.
On 23 Apr 2009, at 14:48, Ignat Zapolsky wrote:
> Hi,
>
> I wonder if anyone was thinking about ability for ClassImposterizer
> to forward method calls to original methods?
>
> This can facilitate refactoring of bulky classes by fixing logic of
> just one method, not a series of (public / protected / default)
> methods being called.
>
> PS. I've implemented a hack which allows to do this, but
> unfortunately it is ugly in terms of specifying what method to
> forward, e.g. it is a method with following signature :
>
> public static void forwardMethod(Method m, Object proxy)
Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006
http://www.m3p.co.ukM3P Limited.
Registered office. 2 Church Street, Burnham, Bucks, SL1 7HZ.
Company registered in England & Wales. Number 03689627
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
