0

I read command pattern here in this link Command Design Pattern in Java – Example Tutorial

Its says command pattern

Command pattern is easily extendible, we can add new action methods in receivers and create new Command implementations without changing the client code.

How it is possible client codes has to change if we add new command .Suppose in above code example if I want to add DeleteCommand. Client program main has to change right I mean he was to need code in to client code.

What does the change word means exactly it means ? Does it mean we dont need to change existing code but we can add new code. Is that is the meaning of Extensible of command pattern?

WalterM
  • 2,686
  • 1
  • 19
  • 26
iCode
  • 151
  • 1
  • 5
  • 1
    You have to write a new implementation of the interface for the new command behavior, but any client that deals with the interface need not know the details about how the command is fulfilled. What's so hard to understand? – duffymo Dec 30 '15 at 22:52
  • If it's a JAVA tutorial, why did you even tag this to C#? – Camilo Terevinto Dec 30 '15 at 22:53
  • Question:Client code changes or not ? – iCode Dec 30 '15 at 22:54
  • Yes any client which deals with Interface need not change.But here in this example client creates receiver and sets command.Hence when we add new command say " DeleteCommand" client needs to change his code by adding new code.so what does author mean saying "without changing the client code." I added in C# bcoz I want to see thi by programming geeks irrespective language as it is paradigm of Design logic. – iCode Dec 30 '15 at 22:56

1 Answers1

0

from https://en.wikipedia.org/wiki/Command_pattern

I think this one paragraph does a better job explaining the pattern. than that entire article.

Rationale/Use:

Using command objects makes it easier to construct general components that need to delegate, sequence or execute method calls at a time of their choosing without the need to know the class of the method or the method parameters.

Design:

Four terms always associated with the command pattern are command, receiver, invoker and client. A command object knows about receiver and invokes a method of the receiver. Values for parameters of the receiver method are stored in the command. The receiver then does the work. An invoker object knows how to execute a command, and optionally does bookkeeping about the command execution. The invoker does not know anything about a concrete command, it knows only about command interface. Both an invoker object and several command objects are held by a client object. The client decides which commands to execute at which points. To execute a command, it passes the command object to the invoker object.

The Client doesn't know the inside workings of either the invoker or of the commands. and that is what is good about it. The client can think of them as 'atomic' events that they can start (by passing the command to the receiver) whenever they want.

So for example if I had a video game, I could have a magic book(receiver), some scrolls (commands), there would be a Hero/Heroine that would be the (client), and the magic imp(invoker) that takes the scroll's contents(the command) and knows how to convert it into 'input'(params) for the book(receiver)

(an aside: I just made up that comparison, but I rather like it... Might use that more)

So that is why the link says that 'receiver' methods can be altered without affecting the client code. Because the Client doesn't know the details of the Command nor of the receiver. (nor of the invoker). It just has a 'group of commands' that it can assign to receiver methods how it chooses. Without having to know anything about the internal makeup of any of the 3 other classes.

mawalker
  • 2,072
  • 2
  • 22
  • 34