The Decorator design pattern provides a solution:
Define separate Decorator objects that add responsibilities to an object.
Work through Decorator objects to extend the functionality of an object at run-time.
Describing the Decorator design in more detail is the theme of the following sections.
See Applicability section for all problems Decorator can solve.

• The key idea in this pattern is to work through separate Decorator objects that 'decorate' (add responsibilities to) an (already existing) object.
  A decorator implements the Component interface transparently so that it can act as transparent enclosure of the component that gets decorated.
  "Clients gene­rally can't tell whether they're dealing with the component or its enclosure […]." [GoF, p44]
• Define separate Decorator objects:
  • Define a class (Decorator) that maintains a reference to a Component object (component) and forwards requests to this component (component.operation()).
  • Define subclasses (Decorator1,…) that implement additional functionality (addBehavior()) to be performed before and/or after forwarding a request.
• Because decorators are transparent enclosures of the decorated component, they can be nested recursively to add an open-ended number of responsibilities.
  Changing the order of decorators allows adding any combinations of responsibilities.
  In the above sequence diagram, for example, a client works through two nested decorator objects that add responsibilities to a Component1 object (after forwarding the request).