0

I have a TriggerCaller and a TriggerAction class. The Caller "calls" the do() method on the action, which is set with the TriggerCallers 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?

  • 2
    Take the 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 – jozefg Jul 21 '13 at 21:12
-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...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.