Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

O pattern explicado como Decorator não é na verdade o Composite?

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.

4 respostas
solução!

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:

http://stackoverflow.com/questions/2233952/difference-between-the-composite-pattern-and-decorator-pattern

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?

Este artigo esclareceu pra mim: http://www.andrecelestino.com/delphi-design-patterns-decorator/