Re: [SWTBot-users] Dependency Injection and Inversion of Control

[Ketan P. <ket...@gm...>]

Hi Hans,

Providing an implementation of widgets using the way you recommend seems 
to be an overkill and potential problems for the following reasons:
1. If there is a new api in the interface, then your implementation of 
the interface will break. Which happens very often.
2. Creates unnecessary complications in the code where classes are 
instantiated via reflection, and the actual widget is constructor 
injected into your implementation.

The other alternative which we're doing is to override SWTBotTestCase 
and provide another implementation of the "bot" instance:

public abstract class MySWTBotTestCase extends SWTBotTestCase {
   protected MySWTBot bot = new MySWTBot();
}

Your test cases could extend from MySWTBotTestCase instead.

Also if you need to provide an alternative implementation for say table, 
you'd override the table api to return MySWTBotTable instead of SWTBotTable

MySWTBotTable could extend from SWTBotTable, to override API that is 
broken, or you wish to provide an alternative implementation.

It's a bit of a workaround, but is not very difficult to implement once 
you have the basic infrastructure in place.

Alternatively you could provide a patch for another implementation of 
SWTBot, that's completely API compatible with the existing one, and 
users could use either implementations.

-- Ketan

Hans Schwaebli wrote:
> Hi Ketan,
> 
> here is one idea which I think about for a while.
> 
> It is not so easy to modify SWTBot's behavior by not changing SWTBot 
> code itself.
> 
> Sometimes I might need a different behavior, like a different matching 
> strategy. Or I'd like to use a own implementation of SWTBotTreeItem (or 
> extending the original and just overwriting one method).
> 
> The solution would be to use dependency injection and inversion of 
> control. I haven't worked awful lot with this concept, but it adds a lot 
> of flexibility without code change of 3rd party components.
> 
> This would mean that for example SWTBotTable would be an interface and 
> there would be a SWTBotTableImpl concrete class. People could change the 
> class used by SWTBot by setting it with bot.setTableImpl(new 
> MySWTBotTableImpl()) for instance.
> 
> It would also provide a good workaround until a bug has been solved in 
> SWTBot or so.
>