Goal: make the way of initiating and describing an action generically,
to be filled in with specifics later.  Allows things to vary more
easily (including at run-time) without breaking clients.

  - Separate (i.e., remove the dependence between) the object making
    the request from the object executing the request.
  - Principle: depend on abstractions, not on implementations
    - Don't have code like "if (slot1 == Light) then light.on()" etc.

Remote Control example:
- associate with each button a generic command object: pushing the
  button invokes the command.  
- Thus the remote control is the "invoker."
- Who creates the command object?  That's the "client."  In the
  abstract, the client is the user who configures the remote; in the
  code, this is the main method that contructs the remote control
  object in the first place, initializing it with various commands.
- Finally, who implements the command objects?  These are the
  "receivers."  They do the work that is being encapsulated in a
  command.  In the example, these are the lights, the stereo, the
  oven, etc. which are being controlled by the remote control.

  * Looking at the classes on p. 194, could we have used the Adapter
    pattern instead?  What would be the benefits and drawbacks?

Diner example:
- Order: the command
- Customer: the client
- Receiver: the short order cook
- Invoker: the waiter

Other uses of the command pattern
- Java Executor framework
  - java.util.Runnable interface

In addition to execute(): Undo 
- May need to save state to keep track
  - may need a stack of state representations
  - in the remote control example, you need a Stack in BOTH the remote
  control ( a stack of commands ) and in the individual commands ( a
  stack of the state prior to each button press ).