Composite
# Composite

Entende-se por Composite um padrão de projeto de software utilizado para representar um objeto formado pela composição de objetos similares. Este conjunto de objetos pressupõe uma mesma hierarquia de classes a que ele pertence. Tal padrão é, normalmente, utilizado para representar listas recorrentes - ou recursivas - de elementos. Além disso, este modo de representação hierárquica de classes permite que os elementos contidos em um objeto composto sejam tratados como se fossem um objeto único. Desta forma, os métodos comuns às classes podem ser aplicados, também, ao conjunto agrupado no objeto composto.

## Aplicação

A intenção do padrão Composite é compor objetos em estruturas de árvore para representar hierarquia partes-todo.
Por exemplo, em interfaces gráficas, um elemento gráfico pode ser formado pela composição de vários outros elementos. Uma página de internet pode conter um ou mais ícones, além de caixas de texto e vários outros elementos. Considerando que uma determinada hierarquia de classes indica um Elemento Gráfico como, portanto, a super-classe—comum à todas classes que representam elementos gráficos atômicos. Assim, a "página" pode ser representada tanto como uma classe que contém zero ou mais elementos gráficos. Veja diagrama a seguir.
Outro exemplo são as linguagens de programação. A hierarquia de classes é utilizada para representar os comandos da linguagem. Supondo que a super-classe seria "Comando", teríamos, pois, uma classe de atribuição, além de o comando while e o comando composto - constituído por uma lista de outros comandos normalmente delimitados por indicadores como { e } ou palavras reservadas como begin, end, etc. Normalmente são representados utilizando o padrão composite. Vide também o outro diagrama representado abaixo.
Vale ressaltar que é fundamental implementar cada método do objeto composto para ser aplicável à lista de objetos que possui. Logo, um objeto "cliente" faz necessário ativar o método desenha de um objeto do tipo "Janela". Este método deverá ser capaz de ativar o desenha de objeto que o contém. Desta maneira, será possível interagir com uma composição de objetos da mesma forma que se interage com objetos individuais.

## Estrutura

O diagrama abaixo mostra a estrutura de classes do exemplo de componentes gráficos apresentada acima.
Representa-se, no diagrama de classes acima, a estrutura do padrão composite, sempre composta por uma estrutura auto-referenciada.
O diagrama abaixo mostra a hierarquia de classes pertencente ao exemplo de comandos de linguagem de programação hipotética apresentada.

## Elementos do Padrão

As classes e objetos participantes nesse padrão são:
* Componente
** Declara a interface para objetos nessa composição.
** Implementa o comportamento padrão para a interface comum à todas as classes.
** Declara uma interface para acessar os componentes-filho.
** (Opcional) - Define uma interface para acessar os componentes-pai na estrutura recursiva, e a implementa se for apropriado.
* Folha
** Representa o objeto folha na composição. A folha não tem nenhum componente-filho.
** Define o comportamento para objetos primitivos na composição.
** Herda todos os métodos de Component porém só implementa de fato os que lhe interessam,neste caso o método Operation, nos outros são inseridos exceções que serão geradas em tempo de execução.
* Composite
** Define o comportamento para componentes que possuam componentes-filho.
** Armazena componentes-filho.
** Implementa funções relacionadas aos componentes-filho na interface do Componente.
* Cliente
** Manipula objetos da composição através da interface do Componente.

## Exemplo de Aplicação Prática do Padrão em UML

Imagine que você está fazendo um sistema de gerenciamento de arquivos. Como você já sabe é possível criar arquivos concretos (vídeos, textos, imagens, etc.) e arquivos pastas, que armazenam outros arquivos. O problema é o mesmo, como fazer um design que atenda estes requerimentos?

### Utilizando o padrão Composite

A ideia do Composite é criar uma classe base que contém toda a interface necessária para todos os elementos e criar um elemento especial que agrega outros elementos.
A classe base Arquivo implementa todos os métodos necessários para arquivos e pastas, no entanto considera como implementação padrão a do arquivo, ou seja, caso o usuário tente inserir um arquivo em outro arquivo uma exceção será disparada. Note como a classe ArquivoVideo não tem métodos.
Já na classe que representa a pasta (ArquivoComposite) nós sobrescrevemos o comportamento padrão e repassamos a chamada para todos os arquivos, sejam arquivos ou pastas.
A primeira vantagem, e talvez a mais forte, seja o fato de os clientes do código Composite serem bem simplificados, pois podem tratar todos os objetos da mesma maneira.

## Exemplo de Uso

O exemplo a seguir, escrito em Java, implementa uma classe gráfica, na qual, pode ser uma elipse ou uma composição de diversas outras formas geometrias, que, todas podem ser representadas no gráfico.
Ele pode ser estendido para implementar diversos outras formas geográficas (círculo, quadrado, etc.) no gráfico.

### Java
#### Exemplo Simples

C++

### JavaScript
## Implementação

Para implementar o padrão Composite, é necessário considerar vários aspectos, sendo eles:
* Referências explícitas aos pais: Manter referências dos componentes-filhos para seus pais pode simplificar o percurso e a administração de uma estrutura composta, ou seja, caso seja necessário mover-se para cima ou deletar um componente, isso seria simplificado.
* Compartilhamento de Componentes: Seria reduzido os requisitos de espaço de armazenamento. Porém, quando um componentes não pode ter mais do que um pai, o compartilhamento de componentes torna-se difícil.
* Maximização da interface de Component: Torna os clientes desconhecedores das classes específicas que estão usando.
* Declarando as operações de gerenciamento de filhos:
** Definir a interface de gerenciamento dos filhos na raiz da hierarquia de classes lhe dá transparência porque você pode tratar todos os componentes uniformemente. No entanto, isso diminui a segurança porque os clientes podem tentar fazer coisas sem sentido, como acrescentar e remover objetos das folhas.
** Definir o gerenciamento de filhos na classe Composite lhe dá segurança porque qualquer tentativa de acrescentar ou remover objetos das folhas será detectada em tempo de compilação em uma linguagem com tipos estáticos, como C++. Porém, você perde transparência porque as folhas e os compostos têm interfaces diferentes.
* Uso de caching para melhorar o desempenho: Caso seja necessário percorrer ou pesquisar composições com frequência, a classe composite pode fazer um cache de informações sobre seus filhos para poder realizar a navegação, fazendo com que tenha uma abreviação do percurso ou a busca.
* Garbage Collector: Caso utilizado em linguagens sem garbage collection, o Composite seria o responsável pela deleção de seus filhos, quando esses forem destruídos.

## Consequências do Uso

* Objetos complexos podem ser compostos de objetos mais simples recursivamente. O cliente pode tratar objetos simples ou compostos de maneira uniforme uma vez que é definida uma interface comum (Component) à ambos.
* Facilita a adição de novos componentes: o cliente não tem que mudar com a adição de novos objetos (simples ou compostos).
* Do lado negativo, o projeto fica geral demais.
** É mais difícil restringir os componentes de um objeto composto;
** O sistema de tipagem da linguagem não ajuda a detectar composições erradas.

## Relação com Iterator

O padrão Composite é bastante utilizado com o Iterator para percorrer a estrutura em forma de árvore oferecida pelo primeiro. Imaginemos que há uma classe abstrata Component com vários métodos e um deles é utilizado para imprimir toda estrutura. Esse método printar é herdado tanto pela folha quanto pelo composite, portanto fazendo essa iteração é possível percorrer e imprimir todos os componentes de Component pois tanto a folha quanto o composite são do tipo Component e implementam suas própria versões do método printar.

## Bibliografia e Referências

* Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides (1995). Design Patterns. Elements of Reusable Object-Oriented Software 1 ed. Estados Unidos da América: Addison-Wesley. ISBN 0201633612 !CS1 manut: Nomes múltiplos: lista de autores (link)
* http://www.dofactory.com/net/composite-design-pattern Em falta ou vazio |título= (ajuda)