A extensão de funcionalidades através de herança é um dos mecanismos poderosos da programação orientada a objetos. Entretanto, é um mecanismo pouco flexível -- para acrescentar alguma funcionalidade a uma classe, o código deve ser recompilado. Outra situação onde não é prático usar herança é onde funcionalidades simples podem ser agregadas a diversas classes da aplicação -- o número resultante de classes associadas a cada combinação possível seria enorme.
A solução de projeto para lidar com tais situações de forma controlada é dada pelo padrão Decorator. A aplicação deste padrão de projeto oferece uma alternativa mais dinâmica e flexível à extensão de funcionalidades de uma classe do que aquela suportada através da herança.
A estrutura de classes associada ao padrão Decorator envolve a definição de uma classe abstrata associada à definição das classes que representam os objetos que podem receber o conjunto de funcionalidades especificado (as decorações). Outra classe abstrata é utilizada para definir as classes que agregam essas funcionalidades. Como mais de uma decoração pode ser agregada a um objeto, a classe que agrega a decoração é também uma classe que pode receber uma (outra) decoração.
Neste exemplo, extraído da API do pacote java.io, essas duas classes são respectivamente InputStream, que tem subclasses concretas como FileInputStream, e FilterInputStream, que tem subclasses que são decoradores concretos, tais como BufferedInputStream.