I have builder:
public abstract class ScriptBuilder {
public void buildScript() {
this.commandList = Lists.newArrayList();
}
public abstract void buildSleepCommand(long time);
public abstract void buildSynchronizationCommand();
public abstract void buildTouchDownCommand(TouchPoint touchPoint);
public abstract void buildTouchUpCommand();
public List<String> getScript() {
return commandList;
}
}
Implementation:
public class StandardScriptBuilder extends ScriptBuilder{
…
}
I need to construct a new builder, which implements the new interface. This new interface is based on the interface ScriptBuilder:
class NewScriptBuilder extends StandardScriptBuilder{
public void buildNewCommand(TouchPoint startTouchPoint, TouchPoint endTouchPoint) {
buildTouchDownCommand(startTouchPoint);
buildSynchronizationCommand();
buildTouchDownCommand(endTouchPoint);
}
…
}
Is there any pattern that will extend the existing builder interface and keep builder advantage? I mean, if we extend the interface, we can not do:
ScriptBuilder builder = new NewScriptBuilder();
…
builder.buildNewCommand;
If there is no solution, it is normal to use?:
((NewScriptBuilder)builder).buildNewCommand;
Thx.
I mean: For example, we can use Decorator pattern:
public abstract class Decorator extends ScriptBuilder {...} ...
public class OahDecorator extends Decorator {
...
public void buildNewCommand() {
...
}
}
it is a normal organization of code, or choose a different pattern is?
task – adding new methods in builder.
If you want a class to implement multiple behaviors, you should have it implement multiple interfaces. It’s generally bad practice to code against classes – you sould instead code against interfaces. The difference is subtle, but still quite relevatn and real.
When you find yourself casting explicitly, it usually means that your interfaces are not quite suitable for the task. The goal is to have the client code know as little as possible about the actual type of the objects that it is processing.