Another alternative is to have the UIContext instance be a field in the helper. In other words, something like this:
- Code: Select all
class Helper {
private final IUIContext ui;
public Helper(IUIContext ui) {
this.ui = ui;
}
...
}
This has the advantage of a convenient pointer to a uicontext instance. On the downside, and this is a principle reason I prefer statics, is that accessing helper methods through a helper instance requires us to keep an instance around which, in my opinion, is cumbersome. That is, I prefer:
- Code: Select all
class Test ... {
public void testA() throws Exception() {
createProject(getUI(), "MyProject");
...
}
}
over:
- Code: Select all
import static Helper.*;
class Test ... {
public void testA() throws Exception() {
getHelper().createProject("MyProject");
...
}
Helper getHelper() {
return new Helper(getUI());
}
}
But it's really 6 of one and a half dozen of the other... (And in fact, the more I look at it, I may like the second pattern more after all! Hmmm... The good news is it's easy to switch down the line if one structure seems better than the other. One thing that might help the decision is to think about whether inheritance --- and specifically overriding behavior --- would be of use in factoring Helpers. At the moment, I'm not sure. But I look forward to finding out!
)
As for your proposed structure, it looks good. As I said before, if you have specific helper needs, post them here (or on a separate thread) or send them to support. After our Ganymede release ships, we'll return to the task of making our existing helpers more available.
Thanks!
-phil