Diferenças entre edições de "Composite"

5 773 bytes removidos ,  01h41min de 18 de novembro de 2011
Reversão. Trechos copiados de [sergiotaborda.wordpress.com/desenvolvimento-de.../composite/]
(Reversão. Trechos copiados de [sergiotaborda.wordpress.com/desenvolvimento-de.../composite/])
'''Composite''' é um [[Padrões de projeto de software|padrão de projeto de software]] queutilizado permitepara querepresentar um [[objeto]] sejaque é constituído depela outroscomposição de objetos semelhantessimilares a ele formando uma hierarquia. Utilizando oNeste padrão, Compositeo éobjeto simplescomposto criar''possui'' umaum hierarquiaconjunto de objetos semelhantes. Semelhantes, significa aqui,outros objetos que implementamestão umana interfacemesma comum.[[Orientação Oa padrãoobjetos#Conceitos simplifica o tratamentosfundamentais|hierarquia]] de cada elemento da hierarquia ao tratar[[classe]]s a todosque comoele implementações da mesma interfacepertence. EsteO padrão pode''composite'' seré usadonormalmente sempreutilizado quepara desejarmos construir objetos pela composição recursiva de objetosrepresentar dolistas mesmorecorrentes tipo- e/ou queiramos[[Recursividade|recursivas]] construir uma hierarquia- de objetos do mesmo tipoelementos. EsteAlém édisso, oesta padrão por detrás da estruturaforma de árvore,representar muitoelementos utilizadacompostos em computação.uma A estruturahierarquia de árvoreclasses tempermite como primitivas as folhas. Os ramos sãoque os objetoselementos compostos.contidos Aem árvoreum éobjeto umacomposto composiçãosejam detratados ramos,como porse suafossem vezum compostosúnico deobjeto. ramosDesta menoresforma, portodos suaos vezmétodos compostoscomuns deàs ramosclasses menoresque erepresentam folhas.objetos Sempreatômicos queda estiverhierarquia perantepoderão umaser estruturaaplicáveis destetambém tipo,ao ouconjunto semelhante,de poderáobjetos usaragrupados ono padrão Compositeobjeto Objectcomposto.
<br />
==Participantes==
*'''Componente''' <br />
:*Declara a interface para objetos na composição; <br />
:*Implementa comportamento ''default'' para interface comum à todas as classes, como apropriado; <br />
:*Declara uma interface para acessar o gerenciar seus Componentes filhos. <br />
 
==Aplicação==
*'''Folha''' <br />
Utilizado sempre que é necessário representar elementos que são compostos por outros elementos similares.
:*Representa objetos folhas na composição. Uma folha não tem filhos; <br />
:*Define comportamento para objetos primitivos na composição. <br />
 
*'''Composição''' <br />
:*Define comportamento para Componentes que têm filhos; <br />
:*Armazena Componentes filhos; <br />
:*Implementa operações relacionadas com filhos na interface do Componente. <br />
 
*'''Cliente''' <br />
:*Manipula objetos na composição através da interface componente. <br />
<br />
Por exemplo, em [[Interface gráfica|interfaces gráficas]] um elemento gráfico pode ser constituído pela composição de vários outros elementos gráficos. Uma janela pode conter um ou mais [[Ícone (informática)|ícones]], uma caixa de texto e vários outros elementos gráficos - até mesmo outra janela. Considerando que uma determinada hierarquia de classes indicasse ''ElementoGráfico'' como a [[Orientação a objetos#Conceitos fundamentais|super-classe]] comum a todas classes que representassem os elementos gráficos atômicos, a classe ''Janela'' seria representada como uma classe que contém zero (0) ou mais elementos gráficos. Veja diagrama a seguir.
==Estrutura==
[[File:Estrutura.jpg|frame|center|Estrutura do Padrão Composite]]
<br />
Outro exemplo clássico é o de [[Gramática#Outras gramáticas|gramáticas]] utilizadas para definir [[Linguagem de programação|linguagens de programação]]. Se utilizarmos uma hierarquia de classes para representar os comandos da linguagem, supondo que a super-classe seria ''Comando'', teríamos uma classe para o comando de atribuição, outro para, digamos, o comando ''[[While]]'', outra para o comando composto - comando que é constituído por uma lista de outros comandos normalmente delimitados por indicadores como ''{'' e ''}'' ou [[palavra reservada|palavras reservadas]] como ''begin'' e ''end'' - e assim por diante. Pois bem, comandos que podem conter outros comandos - como o comando composto ou o comando ''While'' do exemplo - normalmente serão representados utilizando-se o padrão ''composite''. Também é apresentado um diagrama a seguir que representa esta hierarquia.
==O Problema==
Você quer construir um objeto que seja construído de outros objetos tal que, um ou mais objetos desses podem ser do mesmo tipo do objeto construído. O objeto é construído por objetos que contém uma coleção de outros objetos. Os quais contêm uma coleção de outros objetos, e assim sucessivamente. Contudo esses objetos não são quaisquer, eles compartilham uma interface comum. Por exemplo, um objeto do tipo Forma. Existem várias formas, mas todas elas podem ser construídas pela composição de outras formas. Um ou mais formas são primitivas, ou seja, não são construídas a partir de nenhuma forma, outras serão. O exemplo mais simples é a forma Linha que representa uma semi-reta. Um Triângulo é composto por três Linhas. Um quadrado por quatro, e etc. Um círculo não é representável por um conjunto finito de linhas, logo precisamos de uma forma primitiva Circulo. Como construir os objetos do tipo Forma para que eles obedeçam a esta hierarquia é o que o padrão '''Composite''' resolve.
<br />
É importante observar que será responsabilidade do objeto composto, para cada [[método (programação)|método]] a ser aplicável à lista de objetos que possui, implementá-lo de maneira repetitiva. Por exemplo, no caso da hierarquia de elementos gráficos exemplificada, suponha que um objeto cliente ative o método <code>desenha()</code> de um objeto do tipo ''Janela''. Este método deverá ser capaz de ativar os métodos <code>desenha()</code> de cada um dos objetos que ele contém. Desta maneira será possível interagir com uma composição de objetos da mesma forma que se interage com objetos individuais.
==A Solução==
O padrão propõe que se construa uma interface ou classe abstrata que representa o tipo de objeto na hierarquia. Para que o padrão possa ser aplicado tem que existir esta interface ou classe (vou apenas usar o termo interface para simplificar). Objetos que implementam esta interface podem ser de dois tipos: primitivos e compostos. Os objetos primitivos são aqueles que não se podem construir com base em outros objetos do mesmo tipo. Os compostos são aqueles que se constroem com base num conjunto de outros objetos do mesmo tipo. <br />
[[File:Diagrama UML.jpg|frame|center|Diagrama UML representativo do padrão '''Composite''']]
 
==Estrutura==
<br />
O diagrama abaixo mostra a estrutura de classes do exemplo de componentes gráficos apresentada acima.
==Implementação==
Não existe uma implementação específica do padrão '''Composite''' já que o padrão está na relação recursiva entre os objetos compostos e o seu tipo. Um exemplo de uma implementação especifica do padrão '''Composit'''e é o objeto JComponent da API Swing. Este objeto pode conter outros objetos do mesmo tipo numa estrutura de árvore. O Swing utiliza isso para compor objetos visuais que serão apresentados em tela.
 
[[Imagem:ElementoGrafico.jpg|frame||center|Hierarquia de Classes para Elemento Gráfico]]
<br />
==Exemplos na API Padrão==
Na API padrão, Composite Object, é utilizado nas classes java.io.File, javax.swing.JComponent ejavax.swing.tree.TreeNode, por exemplo. Na classe java.io.File acontece a composição de objetos da mesma classe sendo um exemplo do padrãoself-composite para modelar a estrutura de arvores do sistema de arquivos. Na classe javax.swing.JComponent acontece a composição de objetos de classes derivadas. Esta composição é depois traduzida visualmente o que torna esta classe um exemplo do padrão Composite View. Na classe javax.swing.tree.TreeNode acontece a composição de objetos da mesma classe ou classes derivadas, sendo a representação direta de uma estrutura de dados em arvore utilizada pelo componentejavax.swing.JTree.
 
Ressalte-se aí que a estrutura do padrão ''composite'' é sempre composta por uma estrutura auto-referenciada como a do diagrama. O próximo diagrama representa a hierarquia de classes do exemplo de comandos da linguagem de programação hipotética apresentada.
<br />
==Self Composite==
Em algumas situações especiais não existe um objeto primitivo na hierarquia ou a sua interface não se distingue da interface do objeto composto. Neste caso o objeto que representa o tipo de hierarquia é simultaneamente o objeto composto e o objeto primitivo. O objeto composto é constituído de objetos iguais a si mesmo. O objeto é ''self-composite''. <br />
O exemplo clássico deste padrão é o objeto Node que representa um item em uma árvore. Neste caso, um objeto Node contém um ou mais objetos Node. A raíz, ou seja, o primeiro elemento de todos, é também um Node. Não há necessidade de criar vários tipos de classes já que apenas uma classe descreve completamente a hierarquia. <br />
Na API padrão do Java encontramos o objeto java.io.File. O objeto File implementa o padrão self-composite. O objeto representa simultaneamente um arquivo e uma pasta de arquivos num sistema de arquivos (que tem uma estrutura em árvore). Neste caso é utilizada a mesma a interface para tratar ambos os tipos de objeto minimizando o número de classes necessárias para trabalhar com o sistema de arquivos. É interessante notar que ao fundir o elemento primitivo com o composto numa só interface, mas maiorias das vezes, somos obrigados a implementar métodos que nos informam se o elemento é de um ou de outro tipo. Por exemplo, no caso de File os métodos isFile() eisDirectory() informam se o objeto corresponde a um arquivo ou a uma pasta. O padrão ''self-composite'' é interessante em estruturas genéricas em que estamos mais interessados em trabalhar com a estrutura do que com o que ela representa. Este padrão também diminui o número de tipos diferentes necessários para a implementação do padrão, mas o faz à custa de desprezar o polimorfismo ao introduzir métodos para determinar o tipo de componente.
 
[[Imagem:Comando.jpg|frame||center|Hierarquia de Classes para Comando]]
<br />
==Composite View==
Composite View (Visualização composta) é um padrão comum para componentes visuais. A idéia é ter uma interface gráfica montada pela composição de componentes visuais. AWT e Swing são baseados em Composite View. Este padrão também é utilizado em ambiente web em que existe a composição de páginas "template" com as páginas de dados podendo ou não haver uma estrutura composta formal. Algumas tecnologias, como JSF, se aproveitam deste padrão de forma explicita. Produtos como Google Web Toolkit (GWT), Wicked e Web User Interface (WUI) também seu funcionamento em estruturas compostas de componentes visuais.
 
<br />
==Discussão==
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.
<br />
==Padrões relacionados==
* [[Decorator]]
 
==Bibliografia==
* {{Referência a livro|Autor=[[Erich Gamma]], [[Richard Helm]], [[Ralph Johnson]], [[John Vlissides]]|Título=[[Design Patterns: Elements of Reusable Object-Oriented Software|Design Patterns]]|Subtítulo=[[Design Patterns: Elements of Reusable Object-Oriented Software|Elements of Reusable Object-Oriented Software]]|Edição=1|Local de publicação=[[Estados Unidos da América]]|Editora=Addison-Wesley|Ano=1995|ID=ISBN 0201633612}} <br />
* {{Referência a livro|Autor=[[Eric Freeman]], [[Elisabeth Freeman]]|Título=[[Use a Cabeça(''head first'') Padrões de Projeto]]|Local de Publicação=Rio de Janeiro|Editora=Alta Books|Ano=2007}}
 
 
 
22 741

edições