I have a TriggerCaller
and a TriggerAction
class. The Caller “calls” the do()
method on the action, which is set with the TriggerCaller
s setAction()
method. The rest of the program should deal with the Trigger
class, which contains the caller and the action.
I have two options:
1) Give the Trigger
class the methods setAction
and setCaller
. This seems to make sense because it means I won’t have to redefine things for each subclass (see option 2) and I won’t favor one object over the other (see option 3).
2) I can define Trigger
subclasses for each Caller-Action combination. This seems to “feel” better for some reason I can’t articulate, but is impractical. There are simply too many combinations of TriggerCallers and TriggerActions to make.
3) Define a Trigger
subclass for each TriggerCaller
, for instance TriggerMIDI
for the MIDICaller
and give that class a setAction()
. This seems to make sense from a GUI perspective, because in the interface people select the TriggerCaller
type from a “Create” menu and then config it with an action in a dialog (along with other things).
I feel that (1) makes the most sense, but somehow it just feels… wrong. I think that I’m exposing too much of the classes inner workings. I’m also putting the burden on the GUI code of setting the class up (sort of). Is there a better solution? Which one should I choose?
1
I would choose option one but with a small change: Since it seems that a Trigger can not work without an Action and Caller, I would move the injection of those dependencies up to the Trigger’s constructor (and probably remove the setters).
Also:
I'm also putting the burden on the GUI code of setting the class up (sort of).
The responsibility of setting the Trigger’s up should not be on the GUI. I’d create a TriggerFactory whose only responsibility is to create triggers on demand. It would have semantic methods that clients could call to get Triggers fully wired up.
Some examples of those methods could be
TriggerFactory.buildMidiTrigger();
TriggerFactory.buildEmailTrigger();
etc...