The Command design pattern provides a solution:
Encapsulate a request in a separate Command object.
A class delegates a request to a Command object
and doesn't know (is independent of) how the request performed.
Describing the Command design in more detail is the theme of the following sections.
See Applicability section for all problems Command can solve.

• The key idea in this pattern is to encapsulate a request in a separate object that (1) can be used and passed around just like other objects and (2) can be queued or logged to be called at a later point. [BGI]
• Define separate Command objects:
  • Define a common interface for performing a request (Command | execute()).
  • Define classes (Command1,…) that implement the Command interface.
  • A command can implement arbitrary functionality. In the most simple case, it implements a request by calling an operation on a receiver object (receiver1.action1()).
• This enables compile-time flexibility (via inheritance).
  New commands can be added and existing ones can be changed independently by defining new (sub)classes.
• A class (Invoker) delegates the responsibility for performing a request to a Command object (command.execute()).
• This enables run-time flexibility (via object composition).
  A class can be configured with a Command object, which it uses to perform a request, and even more, the Command object can be exchanged dynamically.
  Commands can be stored (in a history list, for example) to be executed or unexecuted at a later time (to queue or log requests and to support undoable operations).