Design Patterns Explained
  • Getting Started
  • SOLID Principles
    • Single Responsibility Principle
    • Open / Closed Principle
    • Liskov Substitution Principle
    • Interface Segregation Principle
    • Dependency Inversion Principle
  • Design Patterns
    • Creational Patterns
      • Abstract Factory Pattern
      • Builder Pattern
      • Factory Pattern
      • Prototype Pattern
      • Singleton Pattern
    • Behavioral Patterns
      • Chain Of Responsibility Pattern
      • Command Pattern
      • Interpreter Pattern
      • Iterator Pattern
      • Mediator Pattern
        • Example 1
      • Memento Pattern
      • Observer Pattern
      • State Pattern
      • Strategy Pattern
        • Example 1
      • Template Method Pattern
      • Visitor Pattern
    • Structural Patterns
      • Adapter Pattern
      • Bridge Pattern
      • Composite Pattern
      • Decorator Pattern
      • Facade Pattern
      • Flyweight Pattern
      • Proxy Pattern
  • Roadmap
Powered by GitBook
On this page
  • Intent
  • When to use
  • Structure
  • Note
  • Examples

Was this helpful?

  1. Design Patterns
  2. Behavioral Patterns

Command Pattern

PreviousChain Of Responsibility PatternNextInterpreter Pattern

Last updated 4 years ago

Was this helpful?

Sometimes there're some operations that are done in multiple places in the client code, it even sometimes affect different objects, so it becomes necessary to encapsulate the code away from the client so the client code doesn't know how to operation is done to avoid redundency.

Intent

Encapsulate an operation as on object that contains all information about the operation, giving the client different operations that can be controlled, manipulated and parametrized by the client (put as a parameter in client code), also to support undoable operations.

When to use

  1. When the client code needs to be parametrized with an action to perform (an object-oriented replacement for callback functions).

  2. When you need to support undo, as commands can be stored with its states and of course then it should provide an (undo / unexecute) interface for the client code to call.

  3. When you want to queue operations, or support scheduling their execution.

  4. Support logging the commands when they're executed so they can be reapplied in case of a crash (backups).

  5. The same operation is shared across multiple places in the client code.

Structure

  • Command: declared the interface for executing an operation (may also introduce the interface for undo operation).

  • ConcreteCommand: defines a binding between the action being executed and the receiver object (so it needs to maintain a reference to the receiver), and implements the execute, and undo by invoking the appropriate corresponding operations in the Receiver. Also its state should be the parameters needed for this operation.

  • Invoker: asks the command to carry out the request, and it should maintain references (one or more) for the executed commands to be able to support undoable operations (it shouldn't be responsible for creating the commands, instead it should be passed a pre-created command from the client).

  • Receiver: class contains some business logic. Almost any object may act as a receiver. Most commands only handle the details of how a request is passed to the receiver, while the receiver itself does the actual work (also commands may not have a receiver if they can do the operation by completely themselves).

Note

The invoker is an optional class in sometimes, but most of the times you'll want one place to manage the execution of the commands to keep track of them.

The Command pattern is usually implemented as prototype pattern, if the commands should be cloned before pushed to the history list or at any other point of time (see Example 1).

Examples

Source Code

UML

// TODO

You can find the tests .

here
Example 1