Builder e Composite: padrões para a sua caixa de ferramentas

Transcrição

1 Builder e Composite: padrões para a sua caixa de ferramentas Boas práticas de desenho/projeto de software Como construir diferentes representações de objetos passo-a-passo e trabalhar com estruturas hierárquicas LEANDRO LUQUE E RODRIGO ROCHA SILVA De que se trata o artigo: O artigo aborda dois padrões de projeto, Builder e Composite, essenciais para a caixa de ferramentas de qualquer desenvolvedor de software, uma vez que é frequente a ocorrência de cenários nos quais a aplicação destes padrões é possível. Para que serve: Para o estudo de boas práticas de desenho/projeto de software orientado a objetos e como guia para empregar os padrões abordados. Em que situação o tema útil: Como a construção de diferentes representações de objetos passo-a-passo e a ocorrência de estruturas hierárquicas é frequente em vários domínios, o conhecimento de boas práticas a eles relacionadas é importante e auxilia no desenvolvimento de software com maior produtividade e melhor qualidade. Builder e Composite: padrões para a sua caixa de ferramentas: Para serem competitivos no cenário atual de desenvolvimento de software, desenvolvedores precisam continuamente aumentar sua produtividade e melhorar a qualidade de seus produtos. Padrões de projeto desempenham um papel de destaque neste contexto, uma vez que podem ser entendidos como uma forma de reuso de soluções para problemas comuns de desenho/projeto de software. Destes problemas, a construção de diferentes representações de objetos passo-a-passo e a ocorrência de estruturas hierárquicas é frequente em vários domínios. Os padrões de projeto Builder e Composite, abordados no artigo, documentam boas práticas relacionadas a estes problemas e auxiliam na modelagem de soluções flexíveis e eficazes.

2 Em diferentes projetos de software, existem características, oportunidades e problemas semelhantes. Podem ser citados como exemplo: criação e gerenciamento de fontes de recursos, centralização do controle de requisições, portabilidade para diferentes Sistemas Gerenciadores de Bancos de Dados (SGBDs), entre outros. Essa semelhança possibilita o reaproveitamento de estratégias e soluções, o que é importante frente ao cenário atual de desenvolvimento de software, no qual é necessário maior produtividade e melhor qualidade para ser competitivo. Padrões de projeto desempenham um papel de destaque neste contexto, uma vez que podem ser entendidos como uma forma de reuso de soluções para problemas comuns de desenho/projeto de software. Um padrão de projeto geralmente especifica um nome, a descrição de um problema/motivação para seu uso, uma solução para o problema apresentado e as consequências da sua aplicação. Além de auxiliarem no aumento da produtividade, principalmente por permitirem o reuso de soluções, e no desenvolvimento de projetos com melhor qualidade, por meio do uso de soluções flexíveis, testadas e documentadas, os padrões de projeto definem um vocabulário comum para a discussão dos problemas para os quais propõem soluções 1. Os padrões de projeto ganharam popularidade com o livro Design Patterns: elements of reusable object-oriented software 2, no qual foram catalogados vinte e três padrões, que foram classificados tanto de acordo com seu propósito (Tabela 1) quanto de acordo com sua intenção (Tabela 2). Propósito Padrões de Projeto Criação Factory Method, Abstract Factory, Builder, Prototype e Singleton. Criação e inicialização de objetos. Estrutura Adapter, Bridge, Composite, Decorator, Facade, Flyweight e Proxy. Composição de classes ou objetos. Comportamento Interpreter, Template Method, Chain of Responsibility, Command, Iterator, Mediator, Memento, Observer, State, Strategy e Visitor. Interação e distribuição de responsabilidades entre classes e objetos. Tabela 1. Classificação dos 23 padrões de projeto proposta pelos autores do livro Design Patterns. Intenção Padrões de Projeto Interfaces Adapter, Bridge, Composite e Facade. Oferecer interfaces. Responsabilidade Chain of Responsibility, Flyweight, Mediator, Observer, Proxy e Singleton. Atribuir responsabilidades. Construção Abstract Factory, Builder, Factory Method, Memento e Prototype. Construir classes ou objetos. Operações Command, Interpreter, State, Strategy e Template Method. Controlar formas de operação. Extensões Decorator, Iterator e Visitor. 1 Apesar de todas essas qualidades, o uso de padrões de projeto deve sempre contar com bom senso. Se forem mal interpretados e empregados, podem diminuir a compreensão do seu projeto e aumentar desnecessariamente a quantidade de código. 2 Padrões de Projeto: soluções reutilizáveis de software orientado a objetos. O livro foi publicado por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, que ficaram conhecidos como Gangue dos Quatro, GoF ou Go4 (Gang of Four).

3 Implementar extensões. Tabela 2. Classificação dos 23 padrões de projeto proposta por Steven John Metsker no livro Design Patterns in Java. Além dos padrões descritos no livro Design Patterns, diversos outros foram catalogados e publicados, tais como: Patterns of Enterprise Application Architecture, Core J2EE Design Patterns: best practices and design strategies, entre outros. Neste artigo, serão abordados dois padrões de projeto: Builder e Composite. O primeiro pode ser empregado com qualquer objeto para o qual seja necessário construir passo-a-passo diferentes representações nestes casos, pode-se dizer que o processo de construção do objeto é complexo. Composite, por sua vez, pode ser empregado na organização e tratamento de estruturas hierárquicas. Como ambos os padrões podem ser empregados com estruturas hierárquicas já que a construção deste tipo de estrutura geralmente envolve processos complexos e o padrão Builder se aplica nesse caso, inicialmente serão analisados alguns domínios nos quais tais estruturas aparecem. Exemplos de domínios nos quais surgem estruturas hierárquicas Venda de produtos Em sistemas de venda de produtos, geralmente existem classes que representam os diferentes tipos de produtos comercializados. Como exemplo, veja, na Figura 1, parte do diagrama de classes de domínio de um sistema para lojas de computadores. Nele, as classes HD, Memoria e PlacaRede representam tipos de produtos vendidos pela loja. Figura 1. Diagrama de classes de uma loja de computadores. Nesses sistemas, também é comum encontrar produtos que são compostos por outros, como é o caso do gabinete do computador, que pode ser composto por HD, Memoria, entre outros. A relação entre essas classes define uma estrutura hierárquica, neste caso, uma árvore. No sistema da loja de computadores, por exemplo, os produtos de um pedido poderiam ser representados pela estrutura da Figura 2.

4 Pedido HD Memoria Gabinete HD Memoria PlacaRede... Figura 2. Estrutura hierárquica em forma de árvore representando um pedido de memória, HD e um gabinete. Essas mesmas características podem ser observadas em sistemas de venda de outros tipos de produto, como: Livros, CDs e DVDs que são vendidos individualmente e em combinações (combos); Itens de roupa vendidos individualmente e em conjunto (como uniformes); Cardápios de lanchonetes e restaurantes, nos quais existem diferentes tipos de pratos e lanches, sendo alguns deles compostos por outros (como o sistema de pedido por números adotado em muitas lanchonetes). Interface gráfica Interfaces gráficas são compostas por diferentes tipos de componentes (rótulos, caixas de texto, caixas de seleção, listas, entre outros), cada um com propriedades e comportamento próprio. Além destes, existem componentes, como janelas e painéis, formados por outros componentes. A Figura 3 apresenta um diagrama de classes simplificado para interfaces gráficas que ilustra a estrutura hierárquica formada pela relação entre seus componentes a API Swing é um exemplo de sistema de interface gráfica no qual surgem estruturas hierárquicas. Figura 3. Estrutura hierárquica de classes para interfaces gráficas. As classes Rotulo e CaixaTexto representam componentes primitivos, que não são compostos por outros, enquanto a classe Painel representa um componente composto por outros. Em alguns sistemas de representação de entes geométricos (pontos, linhas, polígonos), uma estrutura similar pode ser observada, como é o caso da biblioteca TerraLib desenvolvida pelo INPE. Construção de consultas A flexibilidade de um sistema para permitir que seus usuários possam produzir consultas e relatórios personalizados não previstos em tempo de desenvolvimento é um diferencial importante para qualquer aplicação. Para que tal funcionalidade possa ser implementada, deve existir alguma forma de especificar consultas em tempo de execução.

5 Esse tipo de abordagem foi proposto como um padrão, chamado Query Object, por Martin Fowler, no livro Patterns of Enterprise Application Architecture. A API Criteria do Hibernate é um exemplo de implementação deste padrão, na qual existem diferentes tipos de critérios de consulta, como expressões simples de igualdade, diferença, entre outros. Alguns desses critérios, como os lógicos, podem ser compostos por outros. Assim como para o caso da venda de produtos, uma estrutura hierárquica de árvore surge para esse caso. Estruturas como as apresentadas anteriormente surgem em praticamente todos os domínios. Portanto, conhecer os problemas a elas associados é importante para qualquer desenvolvedor de sistemas. Problemas relacionados a estruturas hierárquicas Quando se trabalha com estruturas hierárquicas, tem-se que lidar com questões relacionadas à sua organização, alteração, entre outras. Em alguns casos, essas questões podem se tornar um problema, como quando a estrutura é composta por muitas classes e alterações devem ser realizadas em cada uma delas. O padrão de projeto Composite, que será estudado a seguir, auxilia na solução de problemas relacionados à organização e ao tratamento de estruturas hierárquicas. Para entender o cenário no qual este padrão se aplica, será analisada uma característica comum a todos os domínios apresentados anteriormente. Além do surgimento de estruturas hierárquicas, em todos eles existem operações que podem ser realizadas, tanto em objetos individuais, quanto naqueles que eram compostos de outros. Para o caso da venda de produtos, por exemplo, é necessário obter o preço do produto tanto para produtos individuais, como placas de rede e memórias, quanto para compostos, como gabinetes completos. Para a construção de consultas, é necessário validar e gerar instruções SQL para critérios individuais, como critérios de igualdade, e compostos, como alguns critérios lógicos. Em sistemas de interface gráfica, por sua vez, cada elemento individual, como caixas de texto, ou composto, como painéis, deve ser desenhado. Essas características configuram-se como um cenário apropriado para a aplicação do padrão Composite. Como exemplo ilustrativo da aplicação deste padrão será adotado um sistema de disco virtual, que permite aos seus usuários armazenar e organizar arquivos na Internet. Durante a etapa de modelagem desse sistema, o diagrama de classes representado na Figura 4 foi definido. Nessa figura, estão representadas as duas principais classes de domínio desse sistema: Pasta e Arquivo. Essas classes possuem atributos, métodos e estão relacionadas de forma a permitir que diversas operações possam ser realizadas, tais como o upload e download de arquivos, a criação e exclusão de pastas, entre outras.

6 Figura 4. Diagrama de classes inicial do disco virtual. Algumas destas, como a exclusão, precisam ser realizadas tanto em pastas quanto em arquivos. Para isso, foram definidos métodos para realizá-las tanto na classe Pasta quanto na classe Arquivo, como é o caso de excluirpasta(pasta) e excluirarquivo(arquivo). As pastas e arquivos do disco são apresentados para o usuário por meio de uma estrutura de árvore. Quando o usuário seleciona um item na árvore 3 e, em seguida, alguma opção, como excluir, o código recupera o item atualmente selecionado, verifica qual é seu tipo e executa o método apropriado. Para o caso da exclusão, por exemplo, essa sequência pode ser vista no código da Listagem 1. Se o item for uma pasta, o método excluirpasta() exclui recursivamente todas as pastas e arquivos nela armazenados (Listagem 2). Listagem 1. Código que trata uma solicitação de exclusão de algum nó no disco virtual. 1 //... 2 // se o item selecionado na interface gráfica for uma pasta: 3 if(arvore.getnoselecionado() instanceof Pasta) { 4 ((Pasta)arvore.getNoSelecionado()).excluirPasta(); 5 } 6 // se o item selecionado na interface gráfica for um arquivo: 7 else if(arvore.getnoselecionado() instanceof Arquivo) { 8 ((Arquivo)arvore.getNoSelecionado()).excluirArquivo(); 9 } 10 //... Listagem 2. Código da classe Pasta que exclui recursivamente as subpastas e os arquivos. 1 //... 2 public void excluirpasta() { 3 // itera por todas as subpastas. 4 Iterator<Pasta> subpastas = getsubpastas(); 5 while(subpastas.hasnext()) { 6 Pasta subpasta = subpastas.next(); 7 subpasta.excluirpasta(); 8 remove(subpasta); 9 } // itera por todos os arquivos. 3 Para efeito de simplicidade dos códigos apresentados, assume-se que a árvore gráfica da aplicação é representada por um objeto chamado arvore, cujo método getnoselecionado() retorna um Object representando o item (nó) atualmente selecionado na árvore, que pode ser uma pasta ou arquivo.

7 12 Iterator<Arquivo> arquivos = getarquivos(); 13 while(arquivos.hasnext()) { 14 Arquivo arquivo = arquivos.next(); 15 arquivo.excluirarquivo(); 16 remove(arquivo); 17 } 18 //... código para excluir a pasta atual. 19 } No código da Listagem 1, foi utilizado o método getnoselecionado() para recuperar um objeto que representa um arquivo ou uma pasta. Em seguida, foi verificado a qual tipo se refere e executado o método apropriado. Essa mesma verificação foi feita no código do método excluirpasta(), descrito na Listagem 2. Embora este tipo de abordagem seja válido, o código poderia ter sido simplificado se tivesse sido criada uma classe abstrata ou interface que declarasse os métodos comuns às pastas e arquivos e se fosse aproveitado o polimorfismo para realizar as operações citadas anteriormente (Figura 5), o que permitiria o tratamento uniforme de pastas e arquivos. Figura 5. Diagrama de classes do disco virtual de acordo com o padrão Composite. Os códigos das Listagens 3 e 4 mostram como ficaria o código das operações descritas nas Listagens 1 e 2, respectivamente. Listagem 3. Código que trata uma solicitação de exclusão de algum nó no disco virtual (nova versão). 1 //... 2 ((Item)arvore.getNoSelecionado()).apagar(); 3 //... Listagem 4. Código da classe Pasta que exclui recursivamente as subpastas e os arquivos (nova versão). 1 //... 2 public void apagar() { 3 // itera por os itens. 4 Iterator<Item> itens = getitens(); 5 while(itens.hasnext()) { 6 Item item = itens.next(); 7 item.apagar();

8 8 remove(item); 9 } //... código para excluir a pasta atual. 12 } Não é difícil perceber que o modelo e o código foram otimizados, envolvendo, além da redução do código, um aumento da flexibilidade do sistema para definição de novas classes, já que tipos especiais de arquivos ou pastas podem ser incluídos sem que os códigos anteriores sejam modificados vantagem já bastante conhecida do uso do polimorfismo. O que foi feito quando a modelagem e código foram alterados foi utilizar o padrão Composite, cuja definição será estudada a seguir. Padrão: Composite O padrão Composite envolve a composição de objetos em estruturas de árvore a fim de expressar hierarquias do tipo todo-parte, como aquelas apresentadas nos exemplos de domínios. O padrão permite que objetos individuais (folhas/leafs), como é o caso dos arquivos no disco virtual, e composições de objetos (compostos/composites), como é o caso das pastas, sejam tratados de maneira uniforme. O diagrama de classes que representa a estrutura desse padrão pode ser visto na Figura 6. Figura 6. Diagrama de classes do padrão Composite. Nesse diagrama, as classes Composite e Leaf representam os compostos e as folhas, respectivamente. A classe abstrata Component define os métodos comuns, tanto a folhas, quanto a compostos, o que nos permite, por meio do polimorfismo, tratar folhas e compostos de modo indiferente. A classe Client, por sua vez, representa alguma classe que utiliza a estrutura hierárquica, como é o caso das classes representadas nas Listagens 3 e 4 para o disco virtual. No diagrama do disco virtual, a classe Component é representada pela classe Item e as classes Composite e Leaf são representadas por Pasta e Arquivo, respectivamente. Da forma como foi definido no diagrama da Figura 6, a classe abstrata Component carrega não só os métodos comuns a folhas e compostos, mas também métodos específicos para compostos, como add(), remove() e getchildren(). Esse é um ponto que gera bastante discussão e confusão sobre o padrão.

9 Embora os métodos add(), remove(), entre outros, não façam sentido para folhas, essa abordagem permite manter uma transparência alta para o cliente, uma vez que ele não precisa saber se está lidando com folhas ou compostos. Entretanto, há uma redução da coesão da classe Leaf, porque possui métodos que para ela não fazem sentido. A implementação desses métodos para Leaf pode ser feita de diferentes formas. Uma ideia seria definir uma implementação padrão para esses métodos na classe Component que gere uma exceção (Listagem 5). Essa implementação será sobrescrita por Composite, mas não por Leaf. Portanto, quando os métodos forem executados para folhas, exceções serão lançadas. Outra ideia seria os métodos não fazerem nada, isto é, não executarem código algum. Listagem 5. Código da classe Component que gera, por padrão, exceções para os métodos específicos de compostos. 1 public abstract class Component { 2 3 public abstract void operation(); 4 5 public void add(component component) { 6 throw new UnsupportedOperationException("Operação não suportada!"); 7 } 8 9 public void remove(component component) { 10 throw new UnsupportedOperationException("Operação não suportada!"); 11 } public Component[] getchilden() { 14 throw new UnsupportedOperationException("Operação não suportada!"); 15 } 16 } Uma questão que naturalmente pode surgir é: em que caso pode ser interessante manter uma transparência alta para o cliente interface completamente comum para compostos e folhas e criar soluções para quando alguns métodos forem indevidamente chamados? Na verdade, em poucos casos, esse tipo de abordagem é útil e permite alguma simplificação no código de operações que trabalham com a estrutura hierárquica. Veja um exemplo: deseja-se armazenar um arquivo em todas as pastas do disco virtual, por exemplo, um arquivo.txt, com a lista das subpastas e dos arquivos da pasta outra ideia seria gerar um arquivo que armazena miniaturas das subpastas e dos arquivos da pasta para otimizar sua exibição, semelhante ao que o Windows faz com o arquivo Thumbs.db. Se não for mantida uma interface comum para pastas e arquivos que contenha os métodos necessários para gerar o arquivo.txt, será necessário diferenciar pastas e arquivos no código de geração. Assumindo que tenha sido criado, na classe Pasta, um método chamado gerarlista(), que cria um arquivo.txt com a lista de subpastas e arquivos da pasta, o código da Listagem 6 mostra como poderia ficar o código para gravar os arquivos.txt em cada pasta do disco. Listagem 6. Código que gera os arquivos txt para o disco virtual (versão com interfaces diferentes para Pasta e Arquivo). 1 //... 2 // para cada item do disco virtual: 3 // (nome do item atualmente em processamento: item). 4 if(item instanceof Pasta) { 5 ((Pasta)item).add(((Pasta)item).gerarLista()); 6 } 7 //... Por outro lado, se for mantida uma interface comum para Pasta e Arquivo tal que a classe Component forneça uma implementação padrão, que não faça nada, para o

10 método gerarlista(), conforme especificado na Figura 7, pode-se simplesmente processar todos os itens do disco, executar o método gerarlista(), para gerar o arquivo.txt com a lista de subpastas e pastas da pasta, e o método add() para adicionar o arquivo à pasta. Se o item processado for um arquivo, nada ocorrerá. Se for uma pasta, o arquivo passado por parâmetro será gravado (Listagem 7). Listagem 7. Código que gera os arquivos txt para o disco virtual (versão com interfaces iguais para Pasta e Arquivo). 1 //... 2 // para cada item do disco virtual: 3 // (nome do item atualmente em processamento: item). 4 item.add(item.gerarlista()); 5 //... Esse exemplo mostra porque pode ser interessante manter uma interface comum que, a princípio, pareça conter métodos não significativos para nós folhas para ambos os tipos de nós. Figura 7. Diagrama de classes do disco virtual com mais métodos na interface comum para pastas e arquivos. Como regra, defina na interface comum apenas os métodos para os quais não se deseja fazer distinção entre folha e composto (Figura 8).

11 Figura 8. Diagrama de classes alternativo do padrão Composite. Caso existam vários tipos de compostos e folhas, outras classes abstratas ou interfaces podem ser incluídas no diagrama para manter o que há de comum entre cada um deles em diferentes níveis. A Tabela 3 apresenta um quadro resumo do padrão Composite. Padrão: Composite Classificação Objetivo Estrutura/Interface Compor objetos em uma estrutura de árvore de modo a permitir que clientes tratem, de maneira uniforme, objetos compostos e folha. Problema/Motivação Em muitos sistemas orientados a objetos surgem estruturas hierárquicas de árvore. Muitas vezes, o tratamento diferenciado de objetos compostos e folha resulta em um aumento desnecessário da complexidade do código a ser desenvolvido. Solução Definir uma interface comum (através de classes abstratas ou interfaces) para objetos compostos e folha. Participantes Ver Figura 5 ou 6. Component: classe abstrata ou interface que define o comportamento comum a objetos compostos e folhas; Leaf: subclasse de Component que representa objetos folha; Composite: subclasse de Component que representa objetos compostos; Client: classe que utiliza a estrutura hierárquica formada por componentes. Consequências Torna transparente o tratamento dos componentes da hierarquia, ou seja, permite que objetos compostos e folha sejam tratados de modo indiferente. Facilita a adição de novos tipos de componentes, já que o cliente não precisa mudar quando isso ocorrer. Permite o tratamento de estruturas hierárquicas como um todo, através da chamada de métodos no objeto composto raiz que dispara, recursivamente, métodos em seus componentes.

12 Implementação Dependendo da implementação, a relação entre componentes pode ficar geral demais, o que torna mais difícil a restrição dos possíveis componentes de um objeto composto. A classe Component declara uma interface comum que é implementada nas classes Leaf e Composite. Client utiliza a interface comum de Component para trabalhar com objetos compostos e folhas. Na implementação do padrão, deve-se atentar para a ocorrência de ciclos nas relações entre componentes, pois isto pode resultar em loops infinitos. Um componente pode guardar alguma referência explícita ao componente pai, se for necessário. Tabela 3. Quadro resumo do padrão Composite. Uma aplicação bastante útil do padrão Composite diz respeito à composição dinâmica de interfaces gráficas. Como exemplo desse tipo de aplicação, será admitido o cenário seguinte. Na interface gráfica do disco virtual, deseja-se que o usuário possa enxergar a estrutura de pastas e arquivos tanto através de uma árvore Javascript, quanto através de HTML puro. Além disso, deseja-se personalizar outras partes da interface de acordo com preferências especificadas por usuários. Alguns dos usuários, por exemplo, preferem enxergar a árvore do lado direito da interface, enquanto outros preferem trabalhar com elas do lado esquerdo. O que é necessário para criar tal interface é alguma solução que permita compor dinamicamente uma interface a partir de um layout especificado. O padrão Java EE Composite View, baseado no padrão Composite, foi criado com esse propósito. Ele permite que sejam criadas interfaces gráficas compostas de outras (Figura 9), nas quais o conteúdo e o layout possam ser separados e compostos dinamicamente. Diversos frameworks Java, como Facelets (JSF) e Tiles (Struts), implementam o padrão Composite View. Figura 9. Diagrama de classes do padrão Composite View. Continuando o estudo dos padrões de projeto, será apresentado a seguir um cenário no qual o padrão Builder pode ser empregado. Atualmente, quando necessitam fazer o download de uma pasta inteira, os usuários do disco virtual precisam fazê-lo arquivo por arquivo, o que é muito cansativo. Por este motivo, foram recebidas muitas solicitações para que uma nova funcionalidade de download, que permite o download de pastas inteiras em algum formato de compressão, como ZIP e TAR, seja disponibilizada no sistema.

13 Para oferecer essa nova funcionalidade, poderiam ser escritas diversas classes, uma para cada formato de compressão, que processam a estrutura de pastas do disco e criam o arquivo comprimido. Essa abordagem, no entanto, envolveria a repetição do código de processamento de pastas do disco em todas as classes de criação, o que não é interessante. Para evitar tal repetição, pode ser criada uma classe responsável pelo processamento de pastas que, para cada item do disco, seja pasta ou arquivo, envia uma mensagem para uma classe de compressão que, por sua vez, cria o arquivo comprimido. Essa solução, com o acréscimo de alguns detalhes, é a implementação do padrão de projeto Builder. O diagrama de classes da Figura 10 especifica uma solução para o problema de geração de arquivos comprimidos no disco virtual. Figura 10. Diagrama de classes da funcionalidade de exportação de arquivos comprimidos do disco virtual. Pode-se observar, nesse diagrama, que existe uma classe para processar a estrutura de pastas, AnalisadorItem, e outras que geram cada um dos arquivos comprimidos, CompressorZip e CompressorTAR. A geração dos arquivos comprimidos é conduzida por AnalisadorItem através de sucessivas chamadas feitas aos métodos criarnocomposto() e criarnofolha(), definidos na classe abstrata Compressor. Essa solução separa o processo de construção de arquivos comprimidos, conduzido através da criação de nós compostos e folhas, da representação que será criada, um

14 arquivo ZIP ou um arquivo TAR. Com isso, pode-se, por exemplo, gerar um novo formato de compressão simplesmente adicionando uma nova classe de compressão adequada. Pode-se, inclusive, reaproveitar essa estrutura de classes em outras aplicações que precisam gerar diferentes arquivos comprimidos, a partir da substituição da classe AnalisadorItem por outra apropriada. Nas Listagens 8, 9 e 10, são apresentados os códigos necessários para a geração de arquivos ZIP. É importante ressaltar que na implementação da classe CompressorZIP, o método criarnocomposto() não faz nada porque as pastas (nós compostos) são representadas em um ZIP através do caminho de cada arquivo, tornando-se desnecessária a definição de alguma estrutura específica para representar pastas. Entretanto, esse método será mantido na interface Compressor para permitir que outros tipos de formatos, que envolvam a definição de estruturas específicas para pastas, funcionem corretamente. Listagem 8. Código da classe AnalisadorItem, que processa a estrutura de pastas e arquivos do disco e solicita a um Builder a construção do arquivo comprimido. 1 public class AnalisadorItem { 2 3 private Compressor compressor; 4 private Item raiz; 5 6 public AnalisadorItem(Compressor compressor, Item raiz) { 7 setcompressor(compressor); 8 setraiz(raiz); 9 } public void comprimir() { 12 // para cada item da raiz, recursivamente: 13 // (nome do item atualmente em processamento: item). 14 if(item instanceof Pasta) { 15 compressor.criarnocomposto((pasta)item); 16 } 17 else if(item instanceof Arquivo) { 18 compressor.criarnofolha((arquivo)item); 19 } 20 else { 21 throw new UnsupportedOperationException("Tipo de item desconhecido!"); 22 } 23 } // métodos de acesso. 26 public Compressor getcompressor() { return compressor; } public void setcompressor(compressor compressor) { 29 this.compressor = compressor; 30 } public Item getraiz() { return raiz; } public void setraiz(item raiz) { 35 this.raiz = raiz; 36 } 37 } Listagem 9. Código da classe abstrata Compressor, que define o comportamento comum a compressores de arquivos no disco virtual. 1 public abstract class Compressor { 2 public abstract void criarnocomposto(pasta pasta); 3 public abstract void criarnofolha(arquivo arquivo); 4 } Listagem 10. Código de um compressor para geração de arquivos.zip. 1 import java.io.fileinputstream; 2 import java.io.fileoutputstream;

15 3 import java.io.ioexception; 4 import java.util.zip.zipentry; 5 import java.util.zip.zipfile; 6 import java.util.zip.zipoutputstream; 7 8 public class CompressorZIP extends Compressor { 9 10 private ZipOutputStream out; public CompressorZIP() { 13 // cria um arquivo temporário (FileOutputStream) 14 // onde será armazenado o resultado da compressão. 15 // nome do arquivo: arquivo. 16 FileOutputStream arquivo = // out = new ZipOutputStream(arquivo); 18 } public void criarnocomposto(pasta pasta) { 22 // no caso do ZIP, não é necessário criar 23 // os nós compostos, pois cada nó folha (arquivo) carrega 24 // consigo um caminho completo que representa 25 // a pasta onde se encontra. 26 } public void criarnofolha(arquivo arquivo) { 30 try { 31 // cria uma nova entrada para o arquivo no ZIP. 32 out.putnextentry(new ZipEntry(arquivo.getCaminhoAbsoluto())); 33 // lê o arquivo e o escreve no ZIP. 34 // assume-se que o arquivo, quando é feito o upload no disco, fica armazenado 35 // em um arquivo físico, cujo endereço é armazenado no atributo caminhofisico. 36 // Ele pode ser recuperado através do método getcaminhofisico(), não 37 // representado no diagrama. 38 FileInputStream in = new FileInputStream(arquivo.getCaminhoFisico()); 39 byte[] buffer = new byte[1024]; 40 int tamanho; 41 while((tamanho = in.read(buffer)) > 0) { 42 out.write(buffer, 0, tamanho); 43 } 44 in.close(); 45 } 46 catch(ioexception erro) { 47 erro.printstacktrace(); 48 } 49 } public ZipFile get() { 52 try { 53 out.flush(); 54 out.close(); 55 } 56 catch(ioexception erro) { 57 erro.printstacktrace(); 58 } ZipFile arquivo = new ZipFile(""); 61 return(arquivo); 62 } 63 } A seguir, uma formalização do padrão Builder é apresentada. Padrão: Builder O padrão de criação Builder separa o processo de construção da estrutura de um objeto, de modo que o mesmo processo de construção possa criar várias representações diferentes. Embora não seja o caso do exemplo apresentado para o disco virtual, os objetos gerados por Builder geralmente são estruturas hierárquicas. A solução proposta pelo padrão envolve a definição de uma classe, Director, que fica responsável pela criação do objeto que deseja-se construir, chamado, genericamente, de Product.

16 A classe Director conduz passo-a-passo a criação do produto através de chamadas aos métodos de uma classe de construção. O diagrama de classes desse padrão pode ser visto na Figura 11. Figura 11. Diagrama de classes do padrão Builder. A classe Builder, representada no diagrama, é apenas uma classe abstrata que define os passos necessários para a construção de Product. Essa interface tem necessariamente que ser implementada por uma ou mais classes do tipo ConcreteBuilder, que são as responsáveis por criar alguma representação adequada de Product. No caso do disco virtual, os passos da classe Builder incluíam métodos para construir as diferentes entradas de um arquivo comprimido. O Director recebe como parâmetro a instância de um ConcreteBuilder e usa esta instância para gerenciar a criação dos passos. A Tabela 4 apresenta um quadro resumo do padrão Builder. Padrão: Builder Classificação Objetivo Criação/Construção Separar o processo de construção de um objeto (geralmente uma estrutura hierárquica) de sua representação de forma que o mesmo processo de construção possa criar diferentes representações. Problema/Motivação Muitas vezes, é necessário construir um objeto através de várias etapas de tal forma que, dependendo de parâmetros especificados, diferentes representações desse objeto sejam obtidas. Solução Definir uma interface comum a todos os montadores de objetos e executar o comportamento dessa interface passo-a-passo. Participantes Ver Figura 11. Director: constrói objetos passo-a-passo enviando mensagens a um Builder; Builder: define uma interface (classe abstrata ou interface)

17 Consequências Implementação Tabela 4. Quadro resumo do padrão Builder. que deve ser implementada pelos diferentes construtores de objeto; ConcreteBuilder: define uma implementação da interface Builder; Product: o objeto complexo em construção (inclui classes que definem as partes constituintes). Cria uma independência entre o processo de construção de um objeto de sua representação e, assim, facilita a adição de novas representações. Esconde a forma como as diferentes partes de um objeto são criadas e unidas durante sua construção. Permite um controle maior sobre o processo de construção do objeto, dado que ele é executado passo-a-passo. A classe Builder declara uma interface comum que é implementada nas classes ConcreteBuilder. Client passa um ConcreteBuilder para um Director que, através de sua interface, cria passo-a-passo um Product. No estudo do padrão Builder, podem surgir dúvidas quanto a sua diferença em relação ao padrão Abstract Factory, pois ambos podem ser utilizados na construção de objetos. No entanto, diferentemente do Abstract Factory, Builder constrói objetos passo-apasso. Conclusão O artigo abordou dois padrões de projeto que devem fazer parte da caixa de ferramentas de todo desenvolvedor de sistemas. Um deles, o padrão Builder, permite que diferentes representações de objetos possam ser construídas passo-a-passo e é geralmente empregado em objetos cujo processo de construção é complexo, como é o caso de estruturas hierárquicas. O padrão Composite, por sua vez, auxilia na organização e tratamento de estruturas hierárquicas de forma a facilitar sua manipulação e extensão. Referências Versão digital do livro Design Patterns: elements of reusable object-oriented software. Catálogo de padrões de projeto para o Java Enterprise Edition. Biblioteca virtual sobre padrões de projeto. Exemplos de código Java e C++ para os padrões de projeto do livro Design Patterns.

18 Leandro Luque É professor da Universidade de Mogi das Cruzes (UMC) e da FATEC- Mogi. Tem formação em Ciência da Computação e mestrado em Computação Aplicada pelo Instituto Nacional de Pesquisas Espaciais (INPE). Trabalha com Java há 10 anos, tendo atuado no desenvolvimento de aplicações de grande porte tanto no segmento empresarial quanto governamental. Rodrigo Rocha Silva (rrochas@gmail.com) Formado em Ciência da Computação pela Universidade de Mogi das Cruzes (UMC), mestre em Computação Aplicada pelo INPE e Doutorando pelo ITA. Trabalha com Java há mais de 6 anos, atuando como desenvolvedor, analista e arquiteto em empresas de pequeno e grande porte, nos segmentos de gestão empresarial, saúde e governo. Atua também como professor na UMC e na Veris Faculdades. Possui certificação SCJP 1.4.