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?
Action
+Caller
in the constructor. I don't think there's any reason why you should be able to switch the action or caller on the fly