Composite: diferenças entre revisões

Conteúdo apagado Conteúdo adicionado
Linha 51:
Composite Object é um padrão simples de implementar e serve como base para muitos algoritmos e estruturas, especialmente as que trabalham sobre arvores de objetos. Outro uso do padrão é para conseguir composição de funcionalidades sem ser obrigado a usar o recurso de herança. Um exemplo seria a criação de Validadores. Validadores primitivos seriam responsáveis por validar campos, por exemplo, enquanto um validador composto por esses, poderia validar uma entidade inteira.
 
==== Vantagens ====
:*Define a consistência das hierarquias de classes de objetos primitivos e objetos de composição. <br />
:*Clientes podem tratar estruturas compostas e objetos individuais uniformemente. Clientes normalmente não sabem (e não deveriam se preocupar) se eles estão tratando com uma folha ou uma composição; <br />
:*Torna mais fácil adicionar novos tipos de Componentes. Novas composições ou subclasses. Folhas trabalham automaticamente com estruturas existentes e código do cliente. Clientes não têm que ser mudados para novas classes de Componentes. <br />
 
====Desvantagem====
:*Quando uma composição tem apenas alguns Componentes, você terá de usar uma checagem em tempo de execução para isto.
<br />
==Relação com Outros Padrões==
:*O padrão '''Composite''' é muito comum (especialmente se considerarmos o padrão self-composite) e é extremamente útil, já que estruturas em árvore são muito comuns. <br />
Existem padrões especificamente desenhados para trabalhar sobre hierarquias de objetos como Visitor e Template Method. Outros padrões podem ser agregados para aumentar as capacidades do padrão. Por exemplo, adicionando o padrão Iteratos poderíamos iterar uma árvore em profundidade com simplicidade. <br />
Alguns outros padrões podem ser entendidos como especializações ou usos do padrão '''Composite''' como Query Object , Money Bag e Composite View, por exemplo.