Extra option for ClassImposterizer

[Ignat Zapolsky]

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)


With regards, Ignat Zapolsky.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

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.uk

M3P 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

[Ignat Zapolsky]

Steve,

unfortunately it is not always possible to have great code from the
beginning (assume a legacy code base that was written by programmers of
different skills), thus we are forced to use ClassImposterizer.
And my idea was only to isolate one method of a class under test, but
not to call a method of an external library for which I'll definitely
introduce an interface & proxy object (as was described in your post).

Steve Freeman wrote:

> 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.uk
>
> M3P 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
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Freeman-2]

Understood. We're always in that situation. But, if you have some  
control over the mocked class, I suggest adding an interface to it  
that represents the relationship between it and the object under test.  
Then the target object only deals with the interface and you can mock  
it directly. You get to avoid dealing with the internals of the mocked  
class.

Would that work?

S.

On 23 Apr 2009, at 15:23, Ignat Zapolsky wrote:

> unfortunately it is not always possible to have great code from the  
> beginning (assume a legacy code base that was written by programmers  
> of different skills), thus we are forced to use ClassImposterizer.
> And my idea was only to isolate one method of a class under test,  
> but not to call a method of an external library for which I'll  
> definitely introduce an interface & proxy object (as was described  
> in your post).
>
> Steve Freeman wrote:
>> 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.
>>

Steve Freeman
Winner of the Agile Alliance Gordon Pask award 2006

http://www.m3p.co.uk

M3P 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

[Ignat Zapolsky]

Ehm, this looks like I lack of explanation skills.
For example, I would like to refactor a big fat class with dozens of
public / protected / default access methods which could call other
public / protected / default methods and this class does not have
associated Unit Test (well, it was never written thus class became big &
fat).
And I would like to create a test fixture which will deal with one
public / protected / default method at a time but not with whole stack
of interleaved method invocations.

I hope this description is slightly better than few before.


Steve Freeman wrote:

> Understood. We're always in that situation. But, if you have some
> control over the mocked class, I suggest adding an interface to it
> that represents the relationship between it and the object under test.
> Then the target object only deals with the interface and you can mock
> it directly. You get to avoid dealing with the internals of the mocked
> class.
>
> Would that work?
>
> S.
>
> On 23 Apr 2009, at 15:23, Ignat Zapolsky wrote:
>> unfortunately it is not always possible to have great code from the
>> beginning (assume a legacy code base that was written by programmers
>> of different skills), thus we are forced to use ClassImposterizer.
>> And my idea was only to isolate one method of a class under test, but
>> not to call a method of an external library for which I'll definitely
>> introduce an interface & proxy object (as was described in your post).
>>
>> Steve Freeman wrote:
>>> 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.
>>>
>
> Steve Freeman
> Winner of the Agile Alliance Gordon Pask award 2006
>
> http://www.m3p.co.uk
>
> M3P 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
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email