The Decorator design pattern solves problems like:
How can responsibilities be added to an object dynamically?
How can the functionality of an object be extended at run-time?
See Applicability section for all problems Decorator can solve. See Solution section for how Decorator solves the problems.

• Subclassing is the standard way to extend the functionality of (add responsibilities to) a class statically at compile-time.
  Once a subclass (Subclass1) is instantiated, the functionality is bound to the instance for its life-time and can't be changed at run-time.
• That's the kind of approach to avoid if we want to extend the functionality of an object at run-time instead of extending the functionality of a class at compile-time.
• For example, reusable GUI/Web objects (like buttons, menus, or tree widgets).
  It should be possible to add embellishments (i.e., borders, scroll bars, etc.) to basic GUI/Web objects dynamically at run-time.
• For example, I/O data stream objects [Java Platform].
  It should be possible to add responsibilities like handling data types and buffered data to basic I/O objects that only handle raw binary data (see Sample Code / Example 2).
• For example, collections [Java Collections Framework].
  It should be possible to add automatic synchronization (thread-safety) to a collection or taking away the ability to modify a collection.