Command pattern
I'm new to this design pattern (and this forum too). I would like to know about your experience and advice on command pattern.
Is it OK to implement it this way?
TypicalCommand cmd =new TypicalCommand();
TypicalInput in =new TypicalInput();
in.setProperty1("p1");
in.setProperty2("p2");
cmd.setInput(ti);
cmd.execute();
TypicalOutput out = cmd.getOutput();
or this...
TypicalCommand cmd =new TypicalCommand();
TypicalInput in =new TypicalInput();
in.setProperty1("p1");
in.setProperty2("p2");
TypicalOutput out = cmd.execute(in);
or this...
TypicalCommand cmd =new TypicalCommand();
cmd.setParameter1("p1");
cmd.setParameter2("p2");
cmd.execute();
String result1 = cmd.getResult1();
String result2 = cmd.getResult2();
[1171 byte] By [
bachewa] at [2007-10-2 10:19:17]
Just a comment: it's always a bad idea to define command parameters (or any other kind of parameters) in a fixed ordered list because you are stuck with the order once you want to change something and don't want to break old code. Much better is a position independent way like "para1=val1", "para2=val2". This way you just inspect keys (para1, para2) that can be missing but don't break the other parameters (because their keys don't change compared to the positions of your approach if parameters get removed/added).
Sorry for the confusion,
cmd.setProperty1("p1");
cmd.setProperty2("p2");
property1 and property2 are not related, not a sequence. I just need to illustrate my question only, it's more like...
cmd.setSomeInput(someInput);
cmd.setAnotherInput(anotherInput);
same goes for the output.
I just want to know which way is better (see my first post).
1. Construct input parameters object, pass into command, execute and get output object.
2. Construct input parameters object, pass to execute method and execute and get the returned output object.
3. Set input parameters (command's properties), execute and get output (command's properties as well).
Ah, the old "which is better" question. Which wasn't in your original post, you just wanted to know whether they were "OK".
If they work then they are OK, in my opinion. Except if they are hard to understand, which your examples aren't. So they're OK. This seemed so obvious to me that I couldn't understand the question.
However, if you're comparing the three, I would use the third one, because it doesn't require two extra helper classes that don't do much except encapsulate the input and output data into a single object. Unless those helper objects were required by the design, in which case I wouldn't.
Apply Rule Number 1 of Life, the Universe, and Everything: "IT DEPENDS".
> However, if you're comparing the three, I would use
> the third one, because it doesn't require two extra
> helper classes that don't do much except encapsulate
> the input and output data into a single object.
> Unless those helper objects were required by the
> design, in which case I wouldn't.
Thanks for the input.
Sigh, it tooks several days for me to get only 1 or 2 useful replies.
