The Command design pattern solves problems like:
How can coupling the invoker of a request to a request be avoided? How can an object be configured with a request?
See Applicability section for all problems Command can solve. See Solution section for how Command solves the problems.

• An inflexible way is to implement (hard-wire) a request (receiver1.action1()) directly within the class (Invoker) that invokes the request.
• This commits (couples) the the invoker of a request to a particular request at compile-time and makes it impossible to specify a request at run-time.
  "When you specify a particular operation, you commit to one way of satisfying a request. By avoiding hard-coded requests, you make it easier to change the way a request gets satisfied both at compile-time and run-time." [GoF, p24]
• That's the kind of approach to avoid if we want to configure an object with a request at run-time.
• For example, reusable classes that invoke a request in response to an user input.
  A reusable class should avoid hard-wired requests so that it can be configured with a request at run-time.