Padrão de Projeto Composite

Prévia do material em texto

UNIVERSIDADE DE SÃO PAULO 
FACULDADE DE MEDICINA DE RIBEIRÃO PRETO 
FACULDADE DE FILOSOFIA CIÊNCIAS E LETRAS DE RIBEIRÃO PRETO 
 
 
 IBM1086: PROJETO DE SOFTWARE 
 
 
 
 
 
 
 
 
 
 
 
Padrões de Projeto 
Composite 
 
 
 
 
 
 
 
Camila Aparecida 
Guilherme Guimarães 
Robson Samir 
Wilbert Dener 
 
 
Ribeirão Preto, 2017 
Introdução 
 
1.1. Padrões de projetos 
 
Somente conhecer e utilizar os princípios básicos da orientação a objetos ou de 
uma linguagem de programação, não garante o desenvolvimento de softwares 
flexíveis, reutilizáveis e de fácil manutenção. 
Em Engenharia de Software, padrão de projeto é uma solução geral para um 
problema que ocorre com frequência dentro de um determinado contexto no projeto 
de software. Um padrão de projeto não é um projeto finalizado que pode ser 
diretamente transformado em código fonte ou de máquina, ele é uma descrição ou 
modelo (template) de como resolver um problema que pode ser usado em muitas 
situações diferentes. Padrões são melhores práticas formalizadas que o programador 
pode usar para resolver problemas comuns quando projetar uma aplicação ou sistema. 
A utilização de um padrão de projeto auxilia para tornar o sistema mais fácil 
de entender e manter, fornece soluções que já foram testadas e aprovadas, facilita o 
desenvolvimento de módulos coesos e a comunicação entre os participantes do 
projeto fica mais eficiente. 
 
 
1.2. Composite 
 
Seu principal objetivo é compor objetos em estruturas de árvore para 
representar hierarquia partes-todo. Composite permite aos clientes tratarem de 
maneira uniforme objetos individuais e composições de objetos. 
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. 
Muito utilizado em aplicações gráficas, para construir diagramas complexos a 
partir de componentes simples e agrupar componentes para formar componentes 
maiores. 
Um exemplo de sua utilização seria em uma interfaces gráficas, onde 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. 
 
 
 
2. Estrutura 
 
As classes e objetos participantes nesse padrão são: 
 
Componente 
 
Onde se declara a interface para objetos, implementa o comportamento padrão 
para a interface comum a todas as classes e declara uma interface para acessar 
os componentes filhos 
 
Folha 
A folha não tem nenhum componente-filho. A folha representa o objeto folha 
na composição, define o comportamento para objetos primitivos na 
composição e herda todos os métodos de Component (porém só implementa 
de fato os que lhe interessam) 
 
Composite 
 
Define o comportamento para componentes que possuam componentes-filho, 
armazena componentes-filho e implementa funções relacionadas aos 
componentes-filho na interface do Componente. 
 
Cliente 
 
Manipula objetos da composição através da interface do Componente. 
 
3. Quando usar? 
 
Quando quiser representar hierarquias partes-todos de objetos, quiser que os 
clientes sejam capazes de ignorar a diferença entre composições de objetos e objetos 
individuais, assim os clientes trataram todos os objetos na estrutura composta de 
maneira uniforme. 
4. Consequências do uso 
 
Sua utilização acarreta em alguns benefícios e algumas desvantagens. 
Seus benefícios seriam a recursividade, o composite define hierarquias de 
classe que consistem de objetos primitivos e compostos, torna o cliente simples(eles 
podem tratar estruturas compostas e objetos individuais de maneira uniforme) e torna 
mais fácil acrescentar novas espécies de componentes. Já as suas desvantagens seriam 
que a recursividade ajuda a mascarar defeitos, o projeto fica geral demais, é mais 
difícil restringir os componentes de um objeto composto e o sistema de tipagem da 
linguagem não ajuda a detectar composições erradas. 
 
 
5. Usos Conhecidos 
 
Exemplos do padrão Composite podem ser encontrados em quase todos os sistemas 
orientados a objetos. A classe View original do Model/View/Controller da Smalltalk era um 
Composite, e quase todo toolkit para construção de interfaces de usuário e frameworks 
seguiram os seus passos. É interessante observar que a versão original de View do 
Model/View/Controller tinha um conjunto de “subviews”; em outras palavras, view era tanto 
a classe Component como a classe Composite. O Release 4.0 da Smalltalk-80 revisou o 
Model/View/Controller como uma classe VisualComponent que tem subclasses View e 
CompositeView. O framework compilador RTL Smalltalk [JML92] usa o padrão Composite 
extensamente. A RTL Expression é uma classe Component para árvores de análise (parse 
trees). Ela tem subclasses, tais como BinaryExpression, que contêm objetos-filho 
RTLExpression. Essas classes definem uma estrutura composta para árvores de análise. 
RegisterTransfer é a classe Component para uma forma intermediária Single Static 
Assigment (SSA) de um programa. As subclasses Leaf, de RegisterTransfer, definem 
diferentes atribuições estáticas (static assignments) 
 
6. Padrões Relacionados 
 
 
Freqüentemente, a ligação componente-pai é usada para o padrão Chain of Responsibility. O 
padrão Decorator é freqüentemente usado com o padrão Composite. Quando decoradores e 
composições são usados juntos, eles têm normalmente uma classe-mãe comum. Assim, 
decoradores terão que suportar a interface de Component com operações como Add, Remove 
e GetChild. O Flyweight permite compartilhar componentes, porém estes não mais podem 
referenciar seus pais. O padrão Iterator pode ser usado para percorrer os compostos. O padrão 
Visitor pode ser usado para localizar operações e comportamentos que seriam de outra forma 
distribuídos entre classes Composite e Leaf. 
 
 
 
 
7. Aspectos de implementação - Exemplo 
 
Exemplo de problema: ​Sistema de gerenciamento de arquivos. 
 
Como fazer um design que atenda a requisitos como criar arquivos concretos(videos, textos, 
imagens, etc.) e arquivos pastas? 
 
 
Uma possível solução seria criar uma classe que representa arquivos que são pastas, estas 
pastas teriam uma lista de arquivos concretos e uma lista de arquivos de pastas. Porém existe 
um problema nessa possível solução, como são duas listas diferentes precisaríamos de 
métodos específicos para tratar cada uma dela, ou seja, um método para inserir arquivos e 
outro para inserir pastas, um método para excluir pastas e outro para excluir arquivos, e assim 
por diante. 
 
Sempre que quisermos inserir uma nova funcionalidade no gerenciador precisaremos criar a 
mesma funcionalidade para arquivos e pastas, o que gera um problema de métodos 
duplicados. 
 
A solução para esse problema de métodos duplicados seria utilizar uma classe base Arquivo 
para todos os arquivos, assim precisaríamos apenas de uma lista e de um conjunto de funções 
 
 
 
Assim, seria resolvido o problema dos métodos duplicados porém para fazer a diferenciação 
entre um Arquivo e uma Pasta seria necessário utilizar o “instance of” e verificar qual o tipo 
do objeto, o problema é que seria necessário fazer isso sempre. 
 
 
Uma boa solução para esses problemas seria utilizar o padrão Composite. 
 
 
 No composite a ideia principal é criar uma classe base onde exista toda a interfacenecessária para os elementos juntamente com a criação de um elemento especial que vai 
agregar os outros elementos. 
 Como no diagrama abaixo representa: 
 
 
A classe Arquivo tem esse papel , ou seja, é nela que todos os métodos são 
implementados e usados para criar arquivos e pastas. Deste como se o usuário 
tentar criar um arquivo dentro do próprio arquivo ocorrerá o disparado de um alerta. 
Como no seguinte código: 
 
 
 
Após definir essa classe, para criar um arquivo (por exemplo de vídeo), basta 
implementar um construtor. Como o código abaixo: 
 
Porém para representar a Pasta é necessário sobrescrever os métodos com 
o comportamento padrão e repassar a chamada para todos os arquivos, sejam 
arquivos pasta ou arquivos. Como o código mostra: 
 
Já essa árvore representa o comportamento da estrutura do composite. Nela os 
arquivos concretos do exemplo (gerenciador de arquivos) são as Folhas (Leaf) pois não 
podem gerar filhos e os arquivos pastas são os Nós ou Pais (Node) pois podem gerar filhos 
e fornecer operações para esses. 
 
 
 
8. Referências 
 
GAMMA, Erich et al. Padrões de Projeto: Soluções reutilizáveis de software orientado a 
objetos. 
Padroes de Projeto - Composite < acessado 10 de Novembro de 2017> https: 
//brizeno.wordpress.com