locked
Confusion about command pattern RRS feed

  • Question

  • Hi All,

    In command pattern, it is said that it is to decouple client and the receiver.
    However when i search for code, all the decision about the receiver is made in client only.please find the code below
    static void Main()
        {
          Receiver receiver = new Receiver();
          // Remember that you don´t really need an receiver if you don´t want it.
          Command command = new ConcreteCommand(receiver);
          Invoker invoker = new Invoker();
          invoker.SetCommand(command);
          invoker.ExecuteCommand();
        }

    Can you please let me know how the client and receiver is decoupled.
    I think it can be decoupled only when receiver selection is made in invoker.
    What is your take on this(i might be wrong). Please share any code which is referenced by you for its correct implementation.

    Cheers

    TicArch

    Monday, December 12, 2011 12:32 PM

All replies

  • Hi,

    The Receiver and Command are decoupled at the moment, as long as the Command takes an IReciever interface, because you need to pass an instance of Receiver to the Command. If done right any Receiver can be passed in.

    Yes your not wrong the Invoker could be given the Command and Reciever instances.

    Would that make the design any more or any less decoupled?

    Maybe... probably... but as the code stands there is decoupling at the moment. Is it good enough? or is there more advantage to the Invoker getting both instances?  

    Not sure could you post some code from the Invoker, Receiver and the Command and maybe give us an idea on how they all interact with each other? the communication between these will give another point of view to the decoupling.


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Monday, December 12, 2011 1:58 PM
  • Hi again.

    Never heard before of the Command pattern being used in terms of a 'Receiver'. It's the Observer pattern that usually uses that sort of term.

    Lets see more of the implementation.


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks
    Monday, December 12, 2011 2:05 PM
  • Please find the implementation as given in dofactory (http://www.dofactory.com/Patterns/PatternCommand.aspx#_self1)

    using System;

     

    namespace DoFactory.GangOfFour.Command.Structural

    {

      /// <summary>

      /// MainApp startup class for Structural

      /// Command Design Pattern.

      /// </summary>

      class MainApp

      {

        /// <summary>

        /// Entry point into console application.

        /// </summary>

        static void Main()

        {

          // Create receiver, command, and invoker

          Receiver receiver = new Receiver();

          Command command = new ConcreteCommand(receiver);

          Invoker invoker = new Invoker();

     

          // Set and execute command

          invoker.SetCommand(command);

          invoker.ExecuteCommand();

     

          // Wait for user

          Console.ReadKey();

        }

      }

     

      /// <summary>

      /// The 'Command' abstract class

      /// </summary>

      abstract class Command

      {

        protected Receiver receiver;

     

        // Constructor

        public Command(Receiver receiver)

        {

          this.receiver = receiver;

        }

     

        public abstract void Execute();

      }

     

      /// <summary>

      /// The 'ConcreteCommand' class

      /// </summary>

      class ConcreteCommand : Command

      {

        // Constructor

        public ConcreteCommand(Receiver receiver) :

          base(receiver)

        {

        }

     

        public override void Execute()

        {

          receiver.Action();

        }

      }

     

      /// <summary>

      /// The 'Receiver' class

      /// </summary>

      class Receiver

      {

        public void Action()

        {

          Console.WriteLine("Called Receiver.Action()");

        }

      }

     

      /// <summary>

      /// The 'Invoker' class

      /// </summary>

      class Invoker

      {

        private Command _command;

     

        public void SetCommand(Command command)

        {

          this._command = command;

        }

     

        public void ExecuteCommand()

        {

          _command.Execute();

        }

      }

    }

    Tuesday, December 13, 2011 3:43 AM
  • Hi,

    Chain of responsibility and command patterns are known for decoupling client from receiver.In chain of responsibility, it really happens but in command pattern implementation which we get from dofactory ,it doesn't seems to be the case.

    Can you please refer me to any website which give a clean and simple command pattern implementation

    Cheers

    TicArch

    Tuesday, December 13, 2011 6:05 AM
  • Hi TicArch

    Ok the Command pattern I have used in the past had the Invoker (needed to) but not a Reciever. Essentially the Command was the Receiver. Not a big deal in the GoF book "Any class may serve as a Receiver." ... including the Command itself?  *

    We're on the same page. :)

    I'm looking at the original GoF pattern and for the Command pattern there is only this about the pattern and decoupling.

    "Command decouples the object that invokes the operation from the one that knows how to perform it."

    That's what the code posted does. The Invoker knows nothing about the Receiver.

    If on the other hand the Receiver and Command were passed to the Invoker then the Invoker knows about the object that actually performs the operation? There would be no need for the Command object at all then, the Invoker could just use the Receiver directly?

    What do you think?

     

    *How intelligent should a command be? A command can have a wide range of abilities. At one extreme it merely defines a binding between a receiver and the actions that carry out the request. At the other extreme it implements everything itself without delegating to a receiver at all. The latter extreme is useful when you want to define commands that are independent of existing classes, when no suitable receiver exists, or when a command knows its receiver implicitly


    "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination." - Fred Brooks


    • Edited by Derek Smyth Tuesday, December 13, 2011 2:30 PM
    Tuesday, December 13, 2011 2:22 PM