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.
:*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 />
:*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==
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.
|