Solucionado
Pela explicação e implementação da aula sobre o pattern Decorator, acredito que na verdade tenha sido ensinado o Composite, não?
O Decorator extende a funcionalidade de um objeto em tempo de execução, enquanto o Composite faz com que diversos objetos sejam organizados em uma forma hierárquica e vistos como um único.
No caso da aula, um único objeto inicia toda a cadeia de descontos, o que me parece ser o Composite.
Opa Carlos, tenho a impressão que não. Ele usa diversos objetos que implementam a mesma interface justamente para ir adicionando complexidade na hora de calcular o imposto.. Justamente a ideia do decorator. Não vejo uma ideia de hierarquia entre eles.
Eles são executados em cadeia, como um conjunto de objetos, o que me remete ao padrão Composite. No decorator, eu poderia ter um ImpostoDecorator, que além de aplicar o Imposto, acrescesse juros por atrasos, por exemplo, ou algo do tipo. Porém compor um objeto com diversos outros, pelo que eu entendo, é com o padrão Composite. Entendeu o que eu quis dizer?
Esta resposta no SO me faz reforçar a forma como vejo:
Sobre composite:
"[...] So the essence is th at all elements in your composite structure have the same interface[...]"
Que é exatamente o caso do curso. Todos os objetos da estrutura implementam a interface Desconto.
Já sobre Decorator:
"[...]The decorator pattern allows an entity to completely contain another entity so that using the decorator looks identical to the contained entity.[...]"
Que não é o caso. A classe de desconto mais "acima" só acrescenta o valor da classe mais "abaixo" ao seu próprio no retorno, e não expõe acesso a ela (classe mais "abaixo"), entende?