M

Padres de projeto
M.1 Introduo
A maioria dos exemplos fornecidos neste livro relativamente pequena. No requerem um extenso processo de projeto, pois utilizam poucas classes e ilustram os conceitos introdutrios de programao. Entretanto, alguns programas so mais complexos podem requerer milhares de linhas de cdigo ou mais, eles contm muitas interaes entre objetos e envolvem vrias interaes do usurio. Sistemas maiores, como sistemas de controle de trfego areo ou sistemas que controlam milhares de caixas automticos de um banco importante, poderiam conter milhes de linhas de cdigo. Um projeto eficaz crucial construo adequada desses sistemas complexos. Nas ltimas dcadas, ocorreu na indstria de engenharia de software um enorme progresso no campo dos padres de projeto arquiteturas testadas para construir softwares orientados a objetos flexveis e sustentveis. Utilizar padres de projeto reduz substancialmente a complexidade do processo de design. Projetar um sistema de controle de trfego areo ser uma tarefa menos complexa se desenvolvedores utilizarem padres de projeto. Os padres de projeto beneficiam os desenvolvedores de um sistema ajudando a construir um software confivel com arquiteturas testada e percia acumulada pela indstria. promovendo a reutilizao de projetos em futuros sistemas. ajudando a identificar equvocos comuns e armadilhas que ocorrem ao construirem sistemas. ajudando a projetar sistemas independentemente da linguagem em que eles, em ltima instncia, sero implementados. estabelecendo um vocabulrio comum de projeto entre os desenvolvedores. encurtando a fase de projeto no processo de desenvolvimento de um software. O conceito de utilizao de padres de projeto para construir sistemas de softwares originados no campo da arquitetura. Arquitetos utilizam uma srie de elementos de projetos arquitetnicos estabelecidos, como arcos e colunas, ao projetarem edifcios. Projetar com arcos e colunas uma estratgia testada para construir edifcios perfeitos esses elementos podem ser vistos como padres de projeto arquitetnicos. Nos softwares, os padres de projeto no so classes nem objetos. Em vez disso, os projetistas utilizam padres de projeto para construir conjuntos de classes e objetos. Para utilizar padres de projeto eficientemente, os projetistas devem conhecer os padres mais famosos e eficientes utilizados na indstria de engenharia de software. Neste apndice, discutimos padres e arquiteturas fundamentais de projeto orientados a objetos e sua importncia na construo de softwares bem elaborados. Aqui apresentamos vrios padres de projeto em Java, mas eles podem ser implementados em qualquer linguagem orientada a objetos, como C++ ou Visual Basic. Descrevemos vrios padres de projeto utilizados pela Sun Microsystems na Java API. Utilizamos os padres de projeto em muitos programas neste livro, identificados por toda a nossa discusso. Esses programas fornecem exemplos do uso de padres de projeto para construir softwares orientados a objetos robustos e confiveis.

O histrico dos padres de projeto orientados a objetos Entre 1991 e 1994, Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides coletivamente conhecidos como Gang of Four utilizaram suas percias para escrever o livro Design patterns: elements of reusable object-oriented software. Esse livro descreve 23 padres de projeto, cada um fornecendo uma soluo a um problema comum de projeto de software na indstria. O livro agrupa os padres de projeto em trs categorias padres de projeto criacionais, padres de projeto estruturais e padres de projeto comportamentais. Padres de projeto criacionais descrevem as tcnicas para instanciar objetos (ou grupos de objetos). Padres de projeto estruturais permitem que os projetistas organizem classes e objetos em estruturas maiores. Padres de projeto comportamentais atribuem responsabilidades a classes e objetos.

Apndice M

Padres de projeto

O livro da Gang of Four mostrou que os padres de projeto evoluram naturalmente ao longo dos anos da experincia na indstria. No seu artigo Seven Habits of Successful Pattern Writers,1 John Vlissides afirma que a atividade mais importante no processo de escrever padres a reflexo. Essa afirmao implica que, para criar padres, os desenvolvedores devem refletir sobre, e documentar, seus sucessos (e equvocos). Os desenvolvedores utilizam os padres de projeto para capturar e empregar essa experincia coletiva da indstria que, em ltima instncia, ajuda-os a evitar a repetio dos mesmos equvocos. Novos padres de projeto so criados o tempo todo e apresentados rapidamente aos projetistas do mundo todo via Internet. Os padres de projeto so um tpico mais avanado que talvez no aparea nas seqncias introdutrias da maioria dos cursos. medida que voc avana nos seus estudos sobre o Java, certo que os padres de projeto tero um valor maior. Se voc um aluno e seu instrutor no planeja incluir esse material em seu curso, encorajamos a leitura desse material por conta prpria. A Seo M.8 apresenta uma lista dos recursos da Web que dizem respeito aos padres de projeto e sua relevncia para a programao Java. medida que avana por este apndice, recomendvel consultar os URLs fornecidos para aprender mais sobre um padro de projeto particular introduzido no texto ou para ler sobre novos desenvolvimentos da comunidade dos padres de projeto.

M.2 Introduzindo padres de projeto criacionais, estruturais e comportamentais

Na Seo M.1, mencionamos que a Gang of Four descreveu 23 padres de projeto utilizando trs categorias criacional, estrutural e comportamental. Nesta, e nas outras sees deste apndice, discutimos os padres de projeto em cada categoria e sua importncia e como cada padro se relaciona ao material sobre Java neste livro. Por exemplo, vrios componentes Java Swing que apresentamos nos captulos 11 e 22 utilizam o padro de projeto Composite. A Figura M.1 identifica os 18 padres de projeto da Gang of Four discutidos neste apndice. Muitos padres populares foram documentados com base no livro da Gang of Four estes incluem os padres de projeto de concorrncia, especialmente teis no projeto de sistemas de mltiplas threads. A Seo M.4 discute algum desses padres utilizados na indstria. Padres arquitetnicos, como discutido na Seo M.5, especificam como subsistemas interagem um com o outro. A Figura M.2 lista os padres de concorrncia e os padres arquitetnicos que abordamos neste apndice.

M.2.1 Padres de projeto criacionais

Padres de projeto criacionais examinam questes relacionadas criao de objetos, por exemplo, impedir que um sistema crie mais de um objeto de uma classe (o padro de projeto criacional Singleton) ou postergar, at o tempo de execuo, a deciso sobre quais tipos de objetos sero criados (o propsito dos outros padres de projeto criacionais discutidos aqui). Por exemplo, suponha que estejamos projetando um programa de desenho em 3-D, em que o usurio pode criar vrios objetos geomtricos em 3-D como cilindros, esferas, cubos, tetraedros etc. Suponha ainda que cada forma no programa de desenho seja representada por um objeto. Em tempo de compilao, o programa no sabe quais formas o usurio ir escolher para desenhar. Com base na entrada de usurio, esse programa deve ser capaz de determinar em que classe instanciar um objeto apropriado para a forma que o usurio selecionou. Se o usurio criar um cilindro na GUI, nosso programa deve saber como instanciar um objeto da classe Cylinder. Quando o usurio decide qual objeto geomtrico desenhar, o programa deve determinar em que subclasse especfica instanciar esse objeto.
Seo
Seo M.2 Seo M.3

Padres de projeto criacionais

Singleton Factory Method

Padres de projeto estruturais

Proxy Adapter, Bridge, Composite

Padres de projeto comportamentais

Memento, State Chain of Responsibility, Command, Observer, Strategy, Template Method Iterator

Seo M.5 Seo M.6

Abstract Factory Prototype

Decorator, Facade

Figura M.1 18 padres de projeto da Gang of Four discutidos neste apndice.

Seo
Seo M.4 Seo M.5

Padres de projeto de concorrncia

Single-Threaded Execution, Guarded Suspension, Balking, Read/Write Lock, Two-Phase Termination

Padres arquitetnicos

Model-View-Controller, Layers

Figura M.2

Padres de projeto de concorrncia e arquitetnicos discutidos neste apndice.

O livro da Gang of Four descreve cinco padres criacionais (discutiremos quatro neste apndice): Abstract Factory (Seo M.5) Builder (no discutido)
1

Vlissides, J. Pattern hatching: design patterns applied. Reading, MA: Addison-Wesley, 1998.

M.2

Introduzindo padres de projeto criacionais, estruturais e comportamentais

Factory Method (Seo M.3) Prototype (Seo M.6) Singleton (Seo M.2)

Singleton Ocasionalmente, um sistema deve conter um nico objeto de uma classe depois que o programa instancia esse objeto, ele no deve ter permisso de criar objetos adicionais dessa classe. Por exemplo, alguns sistemas so conectados a um banco de dados utilizando apenas um objeto que gerencia as conexes ao banco de dados, isso assegura que outros objetos no inicializem conexes desnecessrias que tornariam o sistema lento. O padro de projeto Singleton garante que um sistema instancie no mximo um objeto de uma classe. A Figura M.3 demonstra o cdigo Java utilizando o padro de projeto Singleton. A linha 4 declara a classe Singleton como final de modo que no possam ser criadas subclasses que forneceriam mltiplas instanciaes. As linhas 1013 declaram um construtor private somente a classe Singleton pode instanciar um objeto Singleton com esse construtor. A linha 7 declara uma referncia esttica a um objeto Singleton e invoca o construtor privado. Isso cria a instncia da classe Singleton que ser fornecida aos clientes. Quando invocado, o mtodo esttico getSingletonInstance (linhas 1619) simplesmente retorna uma cpia dessa referncia.
1 2 3 4 5
6

// Singleton.Java // Demonstra o padro de projeto Singleton public final class Singleton { // Objeto Singleton a ser retornado por getSingletonInstance private static final Singleton singleton = new Singleton(); // construtor privado impede a instanciao pelos clientes private Singleton() { System.err.println( Singleton object created. ); } // fim do construtor Singleton // retorna o objeto Singleton esttico public static Singleton getInstance() { return singleton; } // fim do mtodo getInstance } // fim da classe Singleton

7 8 9
10

11 12 13 14 15 16 17
18

19 20

Figura M.3 A classe Singleton assegura que somente um objeto de sua classe seja criado.

As linhas 9 e 10 da classe SingletonTest (Figura M.4) declaram duas referncias a objetos Singleton firstSingleton e secondSingleton. As linhas 13 e 14 chamam o mtodo getSingletonInstance e atribuem referncias Singleton a firstSingleton e secondSingleton, respectivamente. A linha 17 testa se essas referncias se referem ao mesmo objeto Singleton. A Figura M.4 mostra que firstSingleton e secondSingleton so de fato referncias ao mesmo objeto Singleton, porque toda vez que o mtodo getSingletonInstance chamado, ele retorna uma referncia ao mesmo objeto Singleton.

M.2.2 Padres de projeto estruturais

Padres de projeto estruturais descrevem maneiras comuns de organizar classes e objetos em um sistema. O livro da Gang of Four descreve sete padres de projeto estruturais (discutiremos seis neste apndice) : Adapter (Seo M.3) Bridge (Seo M.3) Composite (Seo M.3) Decorator (Seo M.5) Facade (Seo M.5) Flyweight (no discutido) Proxy (Seo M.2)

4
1 2 3 4 5 6 7 8 9 10 11 12
13

Apndice M

Padres de projeto

// SingletonTest.java // Tenta criar dois objetos Singleton public class SingletonTest { // executa SingletonExample public static void main( String args[] ) { Singleton firstSingleton; Singleton secondSingleton; // cria objetos Singleton firstSingleton = Singleton.getInstance(); secondSingleton = Singleton.getInstance(); // o dois Singletons devem se referir ao mesmo Singleton if ( firstSingleton == secondSingleton ) System.err.println( firstSingleton and secondSingleton + refer to the same Singleton object ); } // fim de main } // fim da classe SingletonTest

14 15 16 17 18 19 20 21

Singleton object created. firstSingleton and secondSingleton refer to the same Singleton object Figura M.4 A classe SingletonTest cria o objeto Singleton mais de uma vez.

Proxy Um applet sempre deve exibir algo enquanto imagens so carregadas a fim de fornecer um feedback positivo aos usurios para que saibam que o applet est funcionando. Se esse algo for uma imagem menor ou uma string de texto informando o usurio de que as imagens esto sendo carregadas, o padro de projeto Proxy poder ser aplicado para alcanar esse efeito. Considere o carregamento de vrias imagens grandes (vrios megabytes) em um applet Java. Idealmente, gostaramos de ver essas imagens instantaneamente entretanto, o processo para carregar imagens grandes na memria pode demorar (especialmente por uma rede). O padro de projeto Proxy permite que o sistema utilize um objeto chamado objeto proxy no lugar de um outro. No nosso exemplo, o objeto proxy poderia ser uma medida que mostra ao usurio a porcentagem carregada de uma grande imagem.. Quando essa imagem termina de carregar, o objeto proxy no mais necessrio o applet pode ento exibir uma imagem em vez do objeto proxy. A classe javax.swing.JProgressBar pode ser utilizada para criar esses objetos proxy.

M.2.3 Padres de projeto comportamentais

Os padres de projeto comportamentais fornecem estratgias testadas para modelar a maneira como os objetos colaboram entre si em um sistema e oferecem comportamentos especiais apropriados para uma ampla variedade de aplicativos. Vamos considerar o padro de projeto comportamental Observer um exemplo clssico que ilustra colaboraes entre objetos. Por exemplo, componentes GUI colaboram com seus ouvintes para responder a interaes do usurio. Os componentes GUI utilizam esse padro para processar eventos da interface com o usurio. Um ouvinte observa alteraes de estado em um componente GUI particular registrando-se para tratar os eventos nessa GUI. Quando o usurio interage com esse componente GUI, o componente notifica seus ouvintes (tambm conhecido como observadores) de que seu estado mudou (por exemplo, um boto foi pressionado). Tambm consideramos o padro de projeto comportamental Memento um exemplo para oferecer um comportamento especial a muitos aplicativos. O padro Memento permite que um sistema salve o estado de um objeto, de modo que esse estado possa ser restaurado posteriormente. Por exemplo, muitos aplicativos fornecem o recurso desfaz que permite aos usurios reverterem para verses prvias dos seus trabalhos. O livro da Gang of Four descreve 11 padres de projeto comportamentais (discutiremos oito neste apndice): Chain of Responsibility (Seo M.3) Command (Seo M.3) Interpreter (no discutido) Iterator (Seo M.2) Mediator (no discutido) Memento (Seo M.2)

M.3

Padres de projeto utilizados nos pacotes java.awt e javax.swing

Observer (Seo M.3) State (Seo M.2) Strategy (Seo M.3) Template Method (Seo M.3) Visitor (no discutido)

Memento Considere um programa de pintura, que permita a um usurio criar imagens grficas. Ocasionalmente, o usurio talvez posicione uma imagem grfica de maneira inapropriada na rea de desenho. Programas de pintura oferecem o recurso desfazer (undo) que permite ao usurio reverter esse erro. Especificamente, o programa restaura a rea de desenho ao seu estado antes de o usurio ter posicionado a imagem grfica. Programas de pintura mais sofisticados oferecem um histrico, que armazena vrios estados em uma lista, permitindo que o usurio restaure o programa de acordo com qualquer estado no histrico.O padro de projeto Memento permite a um objeto salvar seu estado, de modo que se necessrio o objeto possa ser restaurado ao seu estado inicial. O padro de projeto Memento exige trs tipos de objeto. O objeto originador ocupa algum estado o conjunto de valores dos atributos em um momento especfico na execuo do programa. No nosso exemplo do programa de pintura, a rea de desenho atua como o originador, pois contm informaes sobre o atributo descrevendo seu estado quando o programa executado pela primeira vez, a rea no conter nenhum elemento. O objeto memento armazena uma cpia dos atributos necessrios associados com o estado do originador (o memento salva o estado da rea de desenho). O memento armazenado como o primeiro item na lista de histrico, que atua como o objeto zelador o objeto que contm as referncias a todos os objetos memento associadas ao originador. Agora, suponha que o usurio desenhe um crculo na rea de desenho. A rea contm diferentes informaes que descrevem seu estado um objeto crculo centralizado nas coordenadas x-y especificadas. A rea de desenho ento utiliza um outro memento para armazenar essas informaes. Esse memento torna-se o segundo item na lista de histrico. A lista de histrico exibe todos os mementos na tela, assim o usurio pode selecionar qual estado restaurar. Suponha que o usurio deseje remover o crculo se o usurio selecionar o primeiro memento, a rea de desenho ir utiliz-lo para restaurar a rea de desenho em branco. State Em alguns projetos, devemos comunicar as informaes sobre o estado de um objeto ou representar os vrios estados que um objeto pode ocupar. O padro de projeto State utiliza uma superclasse abstrata chamada classe State que contm os mtodos que descrevem os comportamentos dos estados que um objeto (chamado objeto de contexto) pode ocupar. Uma subclasse State, que estende a classe State, representa um estado individual que o contexto pode ocupar. Cada subclasse State contm os mtodos que implementam os mtodos abstratos da classe State. O contexto contm exatamente uma referncia a um objeto da classe State esse objeto chamado objeto state. Quando o contexto altera o estado, o objeto state faz referncia ao objeto da subclasse State associado a esse novo estado.

M.2.4 Concluso
Nesta seo, listamos os trs tipos de padres de projeto introduzidos no livro da Gang of Four, identificamos 18 desses padres de projeto abordados neste apndice e discutimos padres de projeto especficos, incluindo o Singleton, Proxy, Memento e State. Na prxima seo, introduziremos alguns padres de projeto associados com o AWT e componentes Swing GUI. Depois de ler a prxima seo, voc entender melhor como os componentes GUI Java tiram proveito dos padres de projeto.

M.3 Padres de projeto utilizados nos pacotes java.awt e javax.swing

Esta seo introduz aqueles padres de projeto associados aos componentes GUI Java. Ela ajuda a entender melhor como esses componentes tiram proveito dos padres de projeto e como os desenvolvedores integram padres de projeto a aplicativos da GUI Java.

M.3.1 Padres de projeto criacionais

Agora, continuaremos nosso tratamento dos padres de projeto criacionais que fornecem maneiras de instanciar objetos em um sistema.

Factory Method Suponha que estejamos projetando um sistema que abra uma imagem de um arquivo especificado. H vrios diferentes formatos de imagens, como GIF e JPEG. Podemos utilizar o mtodo createImage da classe java.awt.Component para criar um objeto Image. Por exemplo, para criar uma imagem JPEG e GIF em um objeto de uma subclasse Component como um objeto JPanel passamos o nome do arquivo da imagem para o mtodo createImage, que retorna um objeto Image o qual armazena os dados da imagem. Podemos criar dois objetos Image, cada um contendo dados para duas imagens com estruturas completamente diferentes. Por exemplo, uma imagem JPEG pode conter at 16,7 milhes de cores, uma imagem GIF, apenas 256. Alm disso, uma imagem GIF pode conter pixels transparentes que no so renderizados na tela, enquanto uma imagem JPEG no pode fazer isso. A classe Image uma classe abstrata que representa uma imagem que podemos exibir na tela. Utilizando o parmetro passado pelo programador, o mtodo createImage determina a subclasse Image especfica por meio da qual possvel instanciar o objeto Image. Podemos projetar sistemas para permitir que o usurio especifique a imagem a ser criada, e o mtodo createImage determinar em que subclasse instanciar a Image. Se o parmetro passado para o mtodo createImage fizer referncia a um arquivo JPEG, o mtodo

Apndice M

Padres de projeto

createImage ir instanciar e retornar um objeto de uma subclasse Image adequada para imagens JPEG. Se o parmetro fizer referncia a um arquivo GIF, createImage ir instanciar e retornar um objeto de uma subclasse Image adequada para imagens GIF. O mtodo createImage um exemplo do padro de projeto Factory Method. O propsito exclusivo desse mtodo factory criar

objetos permitindo que o sistema determine qual classe instanciar em tempo de execuo. Podemos projetar um sistema que permita a um usurio especificar qual tipo de imagem criar em tempo de execuo. A classe Component talvez no seja capaz de determinar qual subclasse Image instanciar at que o usurio especifique a imagem a ser carregada. Para informaes adicionais sobre o mtodo createImage, visite
java.sun.com/j2se/5.0/docs/api/java/awt/Component.html

M.3.2 Padres de projeto estruturais

Agora, discutiremos mais trs padres de projeto estruturais. O padro de projeto Adapter ajuda os objetos com interfaces incompatveis a colaborar entre si. O padro de projeto Bridge ajuda os projetistas a aprimorar a independncia de plataformas nos seus sistemas. O padro de projeto Composite fornece uma maneira para que projetistas organizem e manipulem objetos.

Adapter O padro de projeto Adapter fornece a um objeto uma nova interface que se adapta interface de um outro objeto, permitindo que os dois objetos colaborem entre si. Poderamos equiparar o padro adpater a um adaptador de tomada em um dispositivo eltrico soquetes eltricos na Europa tm uma forma diferente daqueles nos Estados Unidos, portanto, necessrio um adaptador para conectar um dispositivo norte-americano a um soquete europeu e vice-versa. O Java fornece vrias classes que utilizam o padro de projeto Adapter. Os objetos das subclasses concretas dessas classes atuam como adaptadores entre objetos que geram certos eventos e objetos que tratam os eventos. Por exemplo, um MouseAdapter, que explicamos na Seo 11.14, adapta um objeto que gera MouseEvents para um objeto que trata MouseEvents. Bridge Suponha que estejamos projetando a classe Button tanto para sistemas operacionais Windows como Macintosh. A classe Button contm informaes especficas sobre o boto como um ActionListener e um rtulo. Projetamos as classes Win32Button e MacButton para estender a classe Button. A classe Win32Button contm informaes sobre a aparncia e comportamento de como exibir um Button no sistema operacional Windows, e a classe MacButton contm informaes sobre a aparncia e comportamento de como exibir um Button no sistema operacional Macintosh. Aqui, surgem dois problemas. Primeiro, se criarmos novas subclasses Button, precisaremos criar subclasses Win32Button e MacButton correspondentes. Por exemplo, se criarmos a classe ImageButton (um Button com uma Image sobreposta) que estende a classe Button, precisaremos criar subclasses Win32ImageButton e MacImageButton adicionais. De fato, precisaremos criar subclasses Button para cada sistema operacional que desejarmos suportar, o que aumenta o tempo de desenvolvimento. Segundo, quando um novo sistema operacional aparecer no mercado, precisaremos criar subclasses Button adicionais especfica para esse novo sistema. O padro de projeto Bridge evita esses problemas dividindo uma abstrao (por exemplo, um Button) e suas implementaes (por exemplo, Win32Button, MacButton etc) em hierarquias de classes separadas. Por exemplo, as classes Java AWT utilizam o padro de projeto Bridge para permitir que os projetistas criem subclasses Button AWT sem a necessidade de criar subclasses adicionais especficas ao sistema operacional. Cada Button AWT mantm uma referncia a um ButtonPeer, que a superclasse para implementaes especficas de plataforma, como Win32ButtonPeer, MacButtonPeer etc. Quando um programador cria um objeto Button, a classe Button chama o mtodo factory createButton da classe Toolkit para criar o objeto ButtonPeer especfico plataforma. O objeto Button armazena uma referncia ao seu ButtonPeer essa referncia a ponte no padro de projeto Bridge. Quando o programador invoca os mtodos no objeto Button, o objeto Button delega o trabalho ao mtodo de nvel mais baixo apropriado no seu ButtonPeer para atender solicitao. Um projetista que cria uma subclasse Button chamada, por exemplo, ImageButton, no precisa criar uma Win32ImageButton ou MacImageButton correspondente com capacidades de desenho de imagens especficas plataforma. Um ImageButton um Button. Portanto, quando um ImageButton precisa exibir sua imagem, o ImageButton utiliza o objeto Graphics do seu ButtonPeer para renderizar essa imagem em cada plataforma. Esse padro de projeto permite que projetistas criem novos componentes GUI para diversas plataformas utilizando uma ponte para ocultar detalhes especficos plataforma.

Dica de portabilidade M.1

Os projetistas costumam utilizar o padro de projeto Bridge a fim de aprimorar a independncia de plataforma dos seus sistemas. Esse padro de projeto permite que projetistas criem novos componentes para diversas plataformas utilizando uma ponte para ocultar detalhes especficos plataforma.

Composite Projetistas freqentemente organizam componentes em estruturas hierrquicas (por exemplo, uma hierarquia de diretrios e arquivos em um sistema de arquivos) cada n na estrutura representa um componente (por exemplo, um arquivo ou diretrio). Cada n pode conter referncias a um ou mais outros ns e, se conter, chamado de ramificao (por exemplo, um diretrio contendo arquivos); caso contrrio, chamado de folha (por exemplo, um arquivo). Algumas vezes, uma estrutura contm objetos de vrias classes diferentes (por exemplo, um diretrio pode conter arquivos e diretrios). Um objeto chamado de cliente que quer percorrer a estrutura para determinar a classe em particular para cada n. Fazer essa determinao pode ser demorado, e a estrutura pode tornar-se difcil de manter.

M.3

Padres de projeto utilizados nos pacotes java.awt e javax.swing

No padro de projeto Composite, cada componente em uma estrutura hierrquica implementa a mesma interface ou estende uma superclasse comum. Esse polimorfismo (introduzido no Captulo 10) assegura que os clientes possam percorrer todos os elementos a ramificao ou folha uniformemente na estrutura sem precisar determinar cada tipo de componente, porque todos os componentes implementam a mesma interface ou estendem a mesma superclasse. Componentes GUI Java utilizam o padro de projeto Composite. Considere a classe de componente Swing JPanel, que estende a classe JComponent. A classe JComponent estende a classe java.awt.Container, que estende a classe java.awt.Component (Figura M.5). A classe Container fornece o mtodo add, que acrescenta um objeto Component (ou objeto da subclasse Component) a esse objeto Container. Portanto, um objeto JPanel pode ser adicionado a qualquer objeto de uma subclasse Component e qualquer objeto de uma subclasse Component pode ser adicionado a esse objeto JPanel. Um objeto JPanel pode conter qualquer componente GUI sem precisar conhecer seu tipo especfico. Quase todas as classes GUI so contineres e componentes, permitindo aninhamento e estruturao arbitrariamente complexa de GUIs. Um cliente, como um objeto JPanel, pode percorrer todos os componentes uniformemente na hierarquia. Por exemplo, se o objeto JPanel chamar o mtodo repaint da superclasse Container, o mtodo repaint exibir o objeto JPanel e todos os componentes adicionados ao objeto JPanel. O mtodo repaint no tem de determinar cada tipo do componente, uma vez que todos os componentes herdam da superclasse Container, que contm o mtodo repaint.

M.3.3 Padres de projeto comportamentais

Esta seo continua a discusso sobre os padres de projeto comportamentais. Discutiremos os padres de projeto Chain of Responsibility, Command, Observer, Strategy e Template Method.

Chain of Responsibility Em sistemas orientados a objetos, os objetos interagem por meio do envio de mensagens. Freqentemente, um sistema precisa determinar em tempo de execuo o objeto que tratar uma mensagem particular. Por exemplo, considere o projeto de um sistema de telefonia com trs linhas para um escritrio. Quando algum chama o escritrio, a primeira linha trata a chamada se a primeira linha estiver ocupada, a segunda tratar a chamada e se a segunda estiver ocupada, a terceira tratar a chamada. Se todas as linhas no sistema estiverem ocupadas, uma secretria eletrnica ir instruir o chamador a esperar a prxima linha disponvel. Quando uma linha estiver disponvel, essa tratar a chamada.
java.awt.Component

java.awt.Container

javax.swing.JComponent

javax.swing.JPanel

Figura M.5 Hierarquia de herana da classe JPanel.

O padro de projeto Chain of Responsibility permite que um sistema determine em tempo de execuo o objeto que tratar uma mensagem. Esse padro permite que um objeto envie uma mensagem para vrios objetos em uma cadeia. Cada objeto na cadeia pode tratar a mensagem ou pass-la para o prximo objeto. Por exemplo, a primeira linha no sistema de telefonia o primeiro objeto na cadeia de responsabilidades, a segunda linha o segundo objeto, a terceira linha o terceiro objeto e a secretria eletrnica o quarto objeto. O objeto final na cadeia a prxima linha disponvel que trata a mensagem. A cadeia criada dinamicamente em resposta presena ou ausncia de operadores especficos de mensagens. Vrios componentes GUI Java AWT utilizam o padro de projeto Chain of Responsibility para tratar certos eventos. Por exemplo, a classe java.awt.Button sobrescreve o mtodo processEvent da classe java.awt.Component para processar objetos AWTEvent. O mtodo processEvent tenta tratar o AWTEvent no recebimento dele como um argumento. Se o mtodo processEvent determinar que o AWTEvent um ActionEvent (que o Button foi pressionado), ele tratar o evento invocando o mtodo processActionEvent, que informa a qualquer ActionListener registrado no Button de que o Button foi pressionado. Se o mtodo processEvent determinar que o AWTEvent no um ActionEvent, o mtodo no ser capaz de trat-lo e ir pass-lo para o mtodo processEvent da superclasse Component (o prximo ouvinte na cadeia).

Command Freqentemente, os aplicativos fornecem aos usurios vrias maneiras de realizar uma dada tarefa. Por exemplo, em um processador de texto pode haver um menu Edit com itens para cortar, copiar e colar texto. Uma barra de ferramentas ou um menu pop-up tambm poderia oferecer os mesmos itens. A funcionalidade que o aplicativo fornece a mesma em cada caso os diferentes componentes de interface para invocar a funcionalidade so oferecidos como uma convenincia ao usurio. Entretanto, a mesma instncia do componente GUI (por

Apndice M

Padres de projeto

exemplo, JButton) no pode ser utilizada para menus, barras de ferramentas e menus pop-up, portanto o desenvolvedor deve codificar a mesma funcionalidade trs vezes. Se houver muitos desses itens na interface, repetir essa funcionalidade seria entediante e propenso a erros. O padro de projeto Command soluciona esse problema permitindo que os desenvolvedores encapsulem, uma vez, a funcionalidade desejada (por exemplo, copiar texto) em um objeto reutilizvel; essa funcionalidade pode ento ser adicionada a um menu, barra de ferramentas, menu pop-up ou outro mecanismo. Esse padro de projeto chamado de Command porque ele define um comando, ou instruo, a ser executado. Ele permite que um projetista encapsule um comando de modo que ele possa ser utilizado entre vrios objetos.

Observer Suponha que queiramos projetar um programa para visualizar as informaes sobre uma conta bancria. Esse sistema inclui a classe BankStatementData para armazenar dados relacionados s instrues do banco e as classes TextDisplay, BarGraphDisplay e PieChartDisplay para exibir os dados. [Nota: Essa abordagem a base do padro arquitetnico Model-View-Controller, discutido na Seo M.5.3.] A Figura M.6 mostra o projeto do nosso sistema. Os dados so exibidos pela classe TextDisplay no formato de texto, pela classe BarGraphDisplay no formato de grfico de barras e pela classe PieChartDisplay como um grfico de pizza. Queremos projetar o sistema de modo que o objeto BankStatementData notifique os objetos que exibem os dados sobre uma alterao nos dados. Tambm queremos projetar o sistema com um acoplamento fraco o grau de dependncia entre classes em um sistema.
Observadores TextDisplay
no a tific

Assunto BankStatementData

notifica
not ifica

BarGraphDisplay

PieChartDisplay

Figura M.6 A base do padro de projeto Observer.

Observao de engenharia de software M.1

Classes com acoplamento fraco so mais fceis de reutilizar e modificar do que classes com acoplamento forte, as quais dependem maciamente uma da outra. A modificao de uma classe em um sistema com um acoplamento fraco normalmente resulta na modificao das outras classes nesse sistema. A modificao para uma classe em um grupo de classes com acoplamento fraco exigiria pouca ou nenhuma modificao nas outras classes.

O padro de projeto Observer apropriado para sistemas como o da Figura M.6. Ele promove o acoplamento fraco entre um objeto-assunto e objetos observadores um objeto-assunto notifica os objetos observadores quando o assunto altera o estado. Quando notificado pelo assunto, os observadores mudam em resposta. No nosso exemplo, o objeto BankStatementData o assunto, e os objetos que exibem os dados so os observadores. Um assunto pode notificar vrios observadores; portanto, o assunto tem um relacionamento de um-para-muitos com os observadores. A Java API contm as classes que utilizam o padro de projeto Observer. A classe java.util.Observable representa um assunto. A classe Observable fornece o mtodo addObserver, que recebe um argumento java.util.Observer. A interface Observer permite que o objeto Observable notifique o Observer quando o objeto Observable altera o estado. O Observer pode ser uma instncia de qualquer classe que implementa a interface Observer; visto que o objeto Observable invoca os mtodos declarados na interface Observer, os objetos permanecem fracamente acoplados. Se um desenvolvedor alterar a maneira como um Observer particular responde s alteraes no objeto Observable, o desenvolvedor no precisar alterar esse objeto. O objeto Observable s interage com seus Observers por meio da interface Observer, que permite acoplamento fraco. Os componentes Swing GUI utilizam o padro de projeto Observer. Os componentes GUI colaboram com seus ouvintes para responder as interaes do usurio. Por exemplo, um ActionListener observa alteraes de estado em um JButton (o assunto) registrando-se para tratar eventos desse JButton. Quando pressionado pelo usurio, o JButton notifica seus objetos ActionListener (os observadores) de que o estado do JButton mudou (que o JButton foi pressionado).

Strategy O padro de projeto Strategy semelhante ao padro de projeto State (discutido na Seo M.2.3). Mencionamos que o padro de projeto State contm um objeto estado, que encapsula o estado de um objeto de contexto. O padro de projeto Strategy contm um objeto strategy, que anlogo ao objeto state do padro de projeto State. A principal diferena que o objeto strategy encapsula um algoritmo em vez de informaes sobre o estado.

M.4

Padres de projeto de concorrncia

Por exemplo, os componentes java.awt.Container implementam o padro de projeto Strategy utilizando LayoutManagers (discutidos na Seo 11.17) como objetos strategy. No pacote java.awt, as classes FlowLayout, BorderLayout e GridLayout implementam a interface LayoutManager. Cada classe utiliza o mtodo addLayoutComponent para adicionar componentes GUI a um objeto Container. Cada mtodo, porm, utiliza um diferente algoritmo para exibir estes componentes GUI: um FlowLayout exibe-os em uma seqncia da esquerda para a direita, um BorderLayout exibe-os em cinco regies e um GridLayout exibe-os no formato linha/coluna. A classe Container contm uma referncia a um objeto LayoutManager (o objeto strategy). Uma referncia de interface (a referncia ao objeto LayoutManager) pode conter referncias aos objetos das classes que implementam essa interface (os objetos FlowLayout, BorderLayout ou GridLayout) de modo que o objeto LayoutManager possa referir-se a um FlowLayout, BorderLayout ou GridLayout a qualquer momento. A classe Container pode alterar essa referncia por meio do mtodo setLayout para selecionar diferentes layouts em tempo de execuo. A classe FlowLayoutFrame (Figura 11.39) demonstra o aplicativo do padro Strategy a linha 23 declara um novo objeto FlowLayout e a linha 25 invoca o mtodo setLayout do objeto Container para atribuir o objeto FlowLayout ao objeto Container. Nesse exemplo, o FlowLayout fornece a estratgia para organizar os componentes.

Template Method O padro de projeto Template Method tambm lida com algoritmos. O padro de projeto Strategy permite que vrios objetos contenham algoritmos distintos. Entretanto, o padro de projeto Template Method requer que todos os objetos compartilhem um nico algoritmo definido por uma superclasse. Por exemplo, considere o projeto da Figura M.6, que apresentamos na discusso sobre o padro de projeto Observer anteriormente nesta seo. Os objetos das classes TextDisplay, BarGraphDisplay e PieChartDisplay utilizam o mesmo algoritmo bsico para adquirir e exibir os dados obtm todas as instrues por meio do objeto BankStatementData, analisam sintaticamente e exibem as instrues. O padro de projeto Template Method permite criar uma superclasse abstrata chamada de BankStatementDisplay que fornece o algoritmo comum para exibio dos dados. Nesse exemplo, o algoritmo invoca os mtodos abstratos getData, parseData e displayData. As classes TextDisplay, BarGraphDisplay e PieChartDisplay estendem a classe BankStatementDisplay para herdar o algoritmo, assim cada objeto pode utilizar o mesmo algoritmo. Cada subclasse BankStatementDisplay ento sobrescreve cada mtodo de uma maneira especfica a essa subclasse, porque cada classe implementa o algoritmo de maneira diferente. Por exemplo, as classes TextDisplay, BarGraphDisplay e PieChartDisplay poderiam obter e analisar sintaticamente os dados de maneira idntica, mas cada uma exibe esses dados de maneira diferente. O padro de projeto Template Method permite estender o algoritmo para outras subclasses BankStatementDisplay por exemplo, poderamos criar classes, como LineGraphDisplay ou a classe 3DimensionalDisplay, que utilizassem o mesmo algoritmo herdado da classe BankStatementDisplay e fornecessem implementaes diferentes dos mtodos abstratos que o algoritmo chama.

M.3.4 Concluso
Nesta seo, discutimos como os componentes Swing tiram proveito dos padres de projeto e como os desenvolvedores podem integrar os padres de projeto a aplicativos GUI em Java. Na seo a seguir, abordaremos os padres de projeto de concorrncia, particularmente teis para desenvolver sistemas de mltiplas threads.

M.4 Padres de projeto de concorrncia

Muitos padres de projeto adicionais foram descobertos desde a publicao do livro da Gang of Four, o qual introduziu padres que envolvem sistemas orientados a objetos. Alguns desses novos padres envolvem tipos especficos de sistemas orientados a objetos, como sistemas concorrentes, distribudos ou paralelos. Nesta seo, abordaremos os padres de concorrncia para complementar nossa discusso sobre a programao de mltiplas threads do Captulo 23.

Padres de projeto de concorrncia Linguagens de programao de mltiplas threads como o Java permitem que projetistas especifiquem atividades concorrentes aquelas que operam em paralelo umas com as outras. Projetar sistemas concorrentes de maneira inapropriada pode introduzir problemas de concorrncia. Por exemplo, dois objetos que tentam, ao mesmo tempo, alterar dados compartilhados poderiam corromper esses dados. Alm disso, se dois objetos esperarem que um ou outro termine as tarefas e se nenhum puder completar sua tarefa, eles potencialmente podero esperar eternamente uma situao denominada de impasse. Utilizando o Java, Doug Lea2 e Mark Grand3 documentaram os padres de concorrncia para arquiteturas de projeto com mltiplas threads a fim de evitar vrios problemas associados com o multithreading. Fornecemos a seguir uma lista parcial desses padres de projeto: O padro de projeto para execuo de uma nica thread (Grand, 2002) impede que vrias threads executem o mesmo mtodo de outro objeto concorrentemente. O Captulo 23 discute vrias tcnicas que podem ser utilizadas para aplicar este padro. O Padro de projeto Guarded Suspension (Lea, 2000) suspende a atividade de uma thread e retoma a atividade dessa thread quando alguma condio for satisfeita. As linhas 8790 e linhas 4144 da classe RunnableObject (Figura 23.17) utilizam
2 3

Lea, D. Concurrent programming in Java. 2. ed. Design principles and patterns. Boston: Addison-Wesley, 2000. Grand, M. Patterns in Java; a catalog of reusable design patterns illustrated with UML. 2. ed. v. I. Nova York: John Wiley and Sons, 2002.

10

Apndice M

Padres de projeto

esse padro de projeto os mtodos await e signal suspendem e retomam as threads de programa e a linha 72 da classe RandomCharacters (Figura 23.18) alterna a varivel de guarda que a condio avalia. O padro de projeto Balking (Lea, 2000) assegura que um mtodo ir emperrar isto , retornar sem realizar nenhuma ao se um objeto ocupar um estado que no possa executar esse mtodo. Uma variao deste padro que o mtodo lana uma exceo que descreve por que esse mtodo no capaz de executar por exemplo, um mtodo que lana uma exceo ao acessar uma estrutura de dados que no existe. O padro de projeto Read/Write Lock (Lea, 2000) permite que mltiplas threads obtenham acesso de leitura concorrente em um objeto, mas impede que mltiplas threads obtenham acesso de gravao concorrente nesse objeto. Somente uma thread por vez pode obter acesso de gravao a um objeto quando essa thread obtm acesso de gravao, o objeto permanece bloqueado para todas as outras threads. O padro de projeto Two-Phase Termination (Grand, 98) utiliza um processo de trmino de duas fases para uma thread a fim de assegurar que ela tenha a oportunidade de liberar recursos como outras threads geradas na memria (primeira fase) antes do trmino (segunda fase). No Java, um objeto Runnable pode utilizar esse padro no mtodo run. Por exemplo, o mtodo run pode conter um loop infinito encerrado por alguma alterao de estado no trmino, o mtodo run pode invocar um mtodo private responsvel por parar quaisquer outras threads geradas (primeira fase). A thread ento termina depois de o mtodo run ser encerrado (segunda fase). Na prxima seo, retornaremos aos padres de projeto da Gang of Four. Utilizando o material apresentado nos captuloc 14 e 24, identificamos as classes no pacote java.io e java.net que usam padres de projeto.

M.5 Padres de projeto utilizados nos pacotes java.io e java.net

Esta seo introduz os padres de projeto associados a pacotes de arquivos, fluxos e redes do Java.

M.5.1 Padres de projeto criacionais

Agora, prosseguiremos nossa discusso sobre padres de projeto criacionais.

Abstract Factory Como ocorre com o padro de projeto de Factory Method, o padro de projeto Abstract Factory permite que um sistema determine em que subclasse instanciar um objeto em tempo de execuo. Com freqncia, essa subclasse no conhecida durante o desenvolvimento. O Abstract Factory, porm, utiliza um objeto conhecido como uma fbrica que usa uma interface para instanciar objetos. Uma fbrica cria um produto que, nesse caso, um objeto de uma subclasse determinada em tempo de execuo. A biblioteca de sockets Java no pacote java.net utiliza o padro de projeto Abstract Factory. Um socket descreve uma conexo, ou um fluxo de dados, entre dois processos. A classe Socket faz referncia a um objeto de uma subclasse SocketImpl (Seo 24.5). A classe Socket tambm contm uma referncia static a um objeto que implementa a interface SocketImplFactory. O construtor Socket invoca o mtodo createSocketImpl da interface SocketImplFactory para criar o objeto SocketImpl. O objeto que implementa a interface SocketImplFactory a fbrica, e um objeto de uma subclasse SocketImpl o produto dessa fbrica. O sistema no pode especificar a subclasse SocketImpl por meio da qual instancia at o tempo de execuo, pois ele no conhece o tipo de implementao de Socket requerido (por exemplo, um socket configurado para os requisitos de segurana da rede local). O mtodo createSocketImpl decide a subclasse SocketImpl da qual instanciar o objeto em tempo de execuo.

M.5.2 Padres de projeto estruturais

Esta seo conclui nossa discusso sobre os padres de projeto estruturais.

Decorator Vamos reexaminar a classe CreateSequentialFile (Figura 14.18). As linhas 20 e 21 dessa classe permitem a um objeto FileOutputStream, que grava bytes em um arquivo, ganhar a funcionalidade de um ObjectOutputStream, que fornece mtodos para gravar objetos inteiros em um OutputStream. A classe CreateSequentialFile aparece para empacotar um objeto ObjectOutputStream em torno de um objeto FileOutputStream. O fato de ser possvel adicionar dinamicamente o comportamento de um ObjectOutputStream a um FileOutputStream evita a necessidade de uma classe separada chamada de ObjectFileOutputStream, que implementaria os comportamentos de ambas as classes. As linhas 20 e 21 da classe CreateSequentialFile mostram um exemplo do padro de projeto Decorator, que permite a um objeto ganhar funcionalidade adicional dinamicamente. Com esse padro, projetistas no tm de criar classes desnecessrias separadas para adicionar responsabilidade a objetos de uma dada classe. Vamos considerar um exemplo mais complexo para descobrir como o padro de projeto Decorator pode simplificar a estrutura de um sistema. Suponha que queiramos aprimorar o desempenho de E/S do exemplo anterior utilizando um BufferedOutputStream. Com o padro de projeto Decorator, escreveramos
output = new ObjectOutputStream( new BufferedOutputStream( new FileOutputStream( fileName ) ) );

M.5

Padres de projeto utilizados nos pacotes java.io e java.net

11

Podemos combinar objetos dessa maneira, porque ObjectOutputStream, BufferedOutputStream e FileOutputStream estendem a superclasse abstrata OutputStream e cada construtor de subclasse recebe um objeto OutputStream como um parmetro. Se os objetos de fluxo no pacote java.io no utilizassem o padro Decorator (se no atendessem a esses dois requisitos), o pacote java.io teria de fornecer as classes BufferedFileOutputStream, ObjectBufferedOutputStream, ObjectBufferedFileOutputStream e ObjectFile OutputStream. Pense no nmero de classes que teramos de criar se combinssemos mais objetos de fluxo sem aplicar o padro Decorator.

Facade Ao dirigir, voc sabe que pisar no acelerador aumenta a velocidade do seu carro, mas no sabe como isso ocorre exatamente. Esse princpio a base do padro de projeto Facade, que permite a um objeto chamado de objeto fachada fornecer uma interface simples para os comportamentos de um subsistema (um agregado de objetos que abrange coletivamente uma responsabilidade importante de sistema). O acelerador, por exemplo, o objeto fachada para o subsistema de acelerao do carro, a direo o objeto fachada para o subsistema de direo do carro e o freio o objeto fachada para o subsistema de desacelerao do carro. Um objeto cliente utiliza o objeto fachada para acessar os objetos por atrs da fachada. O cliente continua a no saber como os objetos por atrs da fachada cumprem com as responsabilidades; a complexidade de subsistema permanece assim oculta do cliente. Ao pressionar o acelerador, voc atua como um objeto cliente. O padro de projeto Facade reduz a complexidade do sistema, porque um cliente interage apenas com um objeto (a fachada) para acessar os comportamentos do subsistema que a fachada representa. Esses desenvolvedores de aplicaes de escudos de padro de complexidades de subsistema. Os desenvolvedores s precisam conhecer as operaes do objeto fachada, em vez de das operaes mais detalhadas do subsistema inteiro. A implementao por atrs da fachada pode ser alterada sem modificaes para os clientes. No pacote java.net, o objeto da classe URL um objeto de fachada. Esse objeto contm uma referncia a um objeto InetAddress que especifica o endereo IP do computador host. O objeto fachada da classe URL tambm faz referncia a um objeto da classe URLStreamHandler, que abre a conexo URL. O objeto cliente que utiliza o objeto fachada da classe URL acessa o objeto de InetAddress e o objeto de URLStreamHandler por meio do objeto fachada. Entretanto, o objeto cliente no sabe como os objetos por trs do objeto fachada da URL cumprem suas responsabilidades.

M.5.3 Padres arquitetnicos

Os padres de projeto permitem que os desenvolvedores projetem partes especficas dos sistemas, como abstrair instanciaes de objetos ou agregar classes a estruturas maiores. Os padres de projeto tambm promovem o acoplamento fraco entre objetos. Padres arquitetnicos promovem o acoplamento fraco entre subsistemas. Esses padres especificam como os subsistemas interagem um com o outro.4 Introduzimos a seguir os populares padres arquitetnicos Model-View-Controller e Camadas (Layers).

MVC Pense no projeto de um editor de textos simples. Nesse programa, o usurio insere texto pelo teclado e o formata utilizando o mouse. Nosso programa armazena esse texto e informaes de formato em uma srie de estruturas de dados e, ento, exibe-as na tela para que o usurio leia o que foi inserido. Esse programa obedece ao padro arquitetnico Model-View-Controller (MVC), que separa os dados do aplicativo (contidos no modelo), de um lado, dos componentes grficos de apresentao (a visualizao) e lgica de processamento de entrada (o controlador), de outro. A Figura M.7 mostra os relacionamentos entre componentes no MVC. O controlador implementa a lgica para processar entradas do usurio. O modelo contm dados do aplicativo e a visualizao apresenta os dados armazenados no modelo. Quando um usurio fornece alguma entrada, o controlador modifica o modelo com a entrada dada. Com referncia ao exemplo do editor de textos, o modelo poderia conter somente os caracteres que compem o documento. Quando o modelo muda, ele notifica a visualizao sobre essa alterao de modo que possa atualizar sua apresentao de acordo com os dados alterados. A visualizao em um processador de textos poderia exibir caracteres que utilizam uma fonte particular com um tamanho particular etc. O MVC no restringe um aplicativo a uma nica visualizao e a um nico controlador. Em um programa mais sofisticado (como um processador de textos), h duas visualizaes de um modelo de documentos. Uma poderia exibir uma estrutura de tpicos do documento e a outra, o documento completo. O processador de textos tambm poderia implementar mltiplos controladores um para tratar entrada pelo teclado e outro para tratar selees de mouse. Se um dos controladores fizer uma alterao no modelo, tanto a visualizao da estrutura de tpicos como a janela de visualizao de impresso mostraro a alterao imediatamente quando o modelo notificar sobre todas as visualizaes das alteraes. Um outro benefcio-chave do padro arquitetnico MVC que os desenvolvedores podem modificar cada componente individualmente sem modificar os outros. Por exemplo, desenvolvedores poderiam modificar a visualizao que exibe a estrutura de tpicos do documento sem modificar o modelo ou outras visualizaes ou controladores.

R. Hartman. Building on patterns. Application Development Trends, p. 1926, maio 2001.

12

Apndice M

Padres de projeto

Controller

modifica Model

notifica

View

Figura M.7

Arquitetura Model-View-Controller.

Camadas (Layers) Pense no projeto na Figura M.8, que apresenta a estrutura bsica de um aplicativo de trs camadas (three-tier application), no qual cada camada contm um componente nico de sistema. A camada de informaes (information tier) tambm chamada de camada inferior, mantm os dados do aplicativo, em geral armazenando esses dados em um banco de dados. A camada de informaes para uma loja on-line poderia conter informaes sobre produtos, como descries, preos e quantidades em estoque e informaes sobre clientes, como nomes dos usurios, endereos de cobrana e nmeros de carto de crdito. A camada intermediria (middle tier) atua como um intermedirio entre a camada de informaes e a camada de cliente. A camada intermediria processa as solicitaes da camada de cliente e l e grava os dados no banco de dados. Ela ento processa os dados da camada de informaes e apresenta o contedo na camada de cliente. Esse processamento a lgica do negcio do aplicativo, a qual trata de tarefas como recuperar dados da camada de informaes, assegurando que esses dados so confiveis antes de atualizar o banco de dados e apresentar os dados na camada de cliente. Por exemplo, a lgica do negcio associada camada intermediria para a loja on-line pode verificar o carto de crdito de um cliente com o emissor do carto de crdito antes da loja enviar o pedido do cliente. Essa lgica do negcio poderia ento armazenar (ou recuperar) as informaes sobre o crdito no banco de dados e notificar a camada de cliente de que a verificao foi bem-sucedida. A camada de cliente (client tier), tambm chamada de camada superior, a interface com o usurio do aplicativo, como um navegador da Web padro. Os usurios interagem diretamente com o aplicativo por meio da interface com o usurio. A camada de cliente interage com a camada intermediria para fazer solicitaes e recuperar dados da camada de informaes. A camada de cliente exibe ento os dados recuperados na camada intermediria.

Camada de cliente (Camada superior)

Camada intermediria

Aplicao

Camada de informaes

Banco de dados

Figura M.8 Modelo de aplicativo de trs camadas (three-tier).

A Figura M.8 uma implementao do padro arquitetnico Layers, que divide as funcionalidades em camadas (layers) separadas. Cada camada contm um conjunto de responsabilidades de sistema e s depende dos servios da prxima camada inferior. Na Figura M.8, cada camada corresponde a uma camada. Esse padro arquitetnico til, porque os projetistas podem modificar uma camada sem alterar as outras. Por exemplo, um projetista poderia modificar a camada de informaes na Figura M.8 a fim de armazenar um produto particular no banco de dados sem alterar a camada do cliente ou a camada intermediria.

M.5.4 Concluso
Nesta seo, discutimos como os pacotes java.io e java.net tiram proveito dos padres de projeto especficos e como os desenvolvedores podem integrar padres de projeto com aplicativos de processamento de redes e arquivos em Java. Tambm apresentamos os padres

M.6

Padres de projeto utilizados no pacote java.util

13

arquitetnicos Model-View-Controller e Camadas (Layers) que atribuem funcionalidades de sistema a subsistemas separados. Esses padres tornam o projeto de um sistema mais fcil aos desenvolvedores. Na prxima seo, concluiremos nossa apresentao dos padres de projeto discutindo os padres utilizados no pacote java.util.

M.6 Padres de projeto utilizados no pacote java.util

Nesta seo, utilizamos o material sobre estruturas de dados e colees discutido nos captulos 17 a 19 para identificar classes no pacote java.util que usam os padres de projeto.

M.6.1 Padres de projeto criacionais

Concluiremos nossa discusso sobre os padres de projeto criacionais apresentando o padro de projeto Prototype.

Prototype s vezes, um sistema deve fazer uma cpia de um objeto sem conhecer a classe desse objeto at o tempo de execuo. Por exemplo, pense no projeto do programa de desenho do Exerccio 10.1 no estudo de caso opcional de GUIs e imagens grficas as classes MyLine, MyOval e MyRect representam as classes forma que estendem a superclasse abstrata MyShape. Podemos modificar esse exerccio para permitir que o usurio crie, copie e cole novas instncias da classe MyLine ao programa. O padro de projeto Prototype permite que um objeto chamado deprottipo retorne uma cpia desse prottipo a um objeto solicitante chamado de cliente. Cada prottipo deve pertencer a uma classe que implementa uma interface comum que permite ao prottipo clonar a si prprio. Por exemplo, a Java API fornece o mtodo clone da classe java.lang.Object e a interface java.lang.Cloneable qualquer objeto de uma classe que implementa Cloneable pode utilizar o mtodo clone para copiar a si mesmo. Especificamente, o mtodo clone cria uma cpia de um objeto e ento retorna uma referncia a esse objeto. Se projetarmos a classe MyLine como o prottipo para o Exerccio 10.1, a classe MyLine deve ento implementar a interface Cloneable. Para criarmos uma linha no nosso desenho, clonamos o prottipo de MyLine. Para copiarmos uma linha preexistente, clonamos esse objeto. O mtodo clone tambm til para mtodos que retornam uma referncia a um objeto, mas em situaes que o desenvolvedor no queira que o objeto seja alterado por essa referncia o mtodo clone retorna uma referncia cpia do objeto em vez de retornar a referncia a esse objeto. Para informaes adicionais sobre a interface Cloneable, visite
java.sun.com/j2se/5.0/docs/api/java/lang/Cloneable.html

M.6.2 Padres de projeto comportamentais

Concluiremos nossa discusso sobre os padres de projeto comportamentais abordando o padro de projeto Iterator.

Iterator Projetistas utilizam estruturas de dados, como arrays, listas vinculadas e tabelas de hash para organizar os dados em um programa. O padro de projeto Iterator permite que objetos acessem objetos individuais em qualquer estrutura de dados sem conhecer o comportamento da estrutura de dados (como percorrer a estrutura ou remover um elemento dessa estrutura) ou como essa estrutura de dados armazena objetos. As instrues para percorrer a estrutura de dados e acessar seus elementos so armazenadas em um objeto separado chamado de iterador. Cada estrutura de dados pode criar um iterador cada iterador implementa os mtodos de uma interface comum para percorrer a estrutura de dados e acessar seus dados. Um cliente pode percorrer duas estruturas de dados diferentemente estruturadas como uma lista vinculada e uma tabela de hash de uma mesma maneira, pois as duas estruturas de dados fornecem um objeto iterador que pertence a uma classe que implementa uma interface comum. O Java fornece a interface Iterator no pacote java.util, discutida na Seo 19.3 a classe CollectionTest (Figura 19.3) que utiliza um objeto Iterator.

M.7 Concluso
Neste apndice, apresentamos a importncia, utilidade e predomnio dos padres de projeto. Em seu livro Design patterns, elements of reusable object-oriented software, a Gang of Four descreveu 23 padres de projeto que fornecem estratgias testadas para construir sistemas. Cada padro pertence a uma entre trs categorias padres criacionais abordam questes relacionada criao de objetos; padres estruturais fornecem maneiras de organizar classes e objetos em um sistema; e padres comportamentais oferecem estratgias para modelar a maneira como objetos colaboram uns com os outros em um sistema. Dos 23 padres de projeto, discutimos 18 dos mais populares utilizados pela comunidade Java. A discusso foi dividida de acordo com a maneira como certos pacotes da Java API pacotes java.awt, javax.swing, java.io, java.net e java.util usam esses padres de projeto. Tambm discutimos os padres no descritos pela Gang of Four, como os de concorrncia, que so teis em sistemas de mltiplas threads, e os arquitetnicos, que ajudam os projetistas a atribuir funcionalidades a vrios subsistemas em um sistema. Motivamos o uso de cada padro explicamos por que importante e tambm como pode ser utilizado. Quando apropriado, fornecemos vrios exemplos de analogias prticas (por exemplo, o adaptador no padro de projeto Adapter semelhante a um adaptador de tomada em um dispositivo eltrico). Voc tambm aprendeu como os pacotes da Java API tiram proveito dos padres de projeto (por exemplo, componentes Swing GUI usam o padro de projeto Observer para colaborar com seus ouvintes a fim de responder s interaes dos usurios). Fornecemos exemplos de como certos programas neste livro utilizaram os padres de projeto.

14

Apndice M

Padres de projeto

Esperamos que examine este apndice como o incio de um estudo mais aprofundado dos padres de projeto. Esses so utilizados mais predominantemente pela comunidade J2EE (Java 2 Platform, Enterprise Edition), em que os sistemas tendem a ser excessivamente grandes e complexos e nos quais a robustez, portabilidade e desempenho so bastante crticos. Entretanto, mesmo os programadores iniciantes podem se beneficiar da exposio inicial aos padres de projetos. Recomendamos que voc visite os vrios URLs que fornecemos na Seo M.8 e que ento leia o livro da Gang of Four. Essas informaes o ajudaro a construir sistemas melhores utilizando a sabedoria coletiva da tecnologia de objetos da indstria. Esperamos que voc continue seus estudos dos padres de projeto. Envie seus comentrios, crticas e sugestes para aperfeioar ainda mais o Java Como Programar a deitel@deitel.com. Boa sorte!

M.8 Recursos da Web

Os URLs a seguir fornecem informaes adicionais sobre a natureza, importncia e aplicaes dos padres de projeto.

Padres de projeto
www.hillside.net/patterns

Exibe links s informaes sobre padres de projetos e linguagens.

www.hillside.net/patterns/books/

Lista livros sobre padres de projeto.

www.netobjectives.com/design.htm

Introduz a importncia dos padres de projeto.

umbc7.umbc.edu/~tarr/dp/dp.html

Conecta a sites da Web de tutoriais e artigos dobre padres de projetos.

www.c2.com/ppr/

Discute os avanos recentes nos padres de projeto e idias para projetos futuros.
www.dofactory.com/patterns/Patterns.aspx

Fornece diagramas de classes da UML que ilustram cada um dos 23 padres de projeto da Gang of Four.

Padres de projeto no Java

java.sun.com/blueprints/patterns/index.html

Pgina de recursos da Sun Microsystems descrevendo os padres de projeto para aplicativos Java 2 Platform, Enterprise Edition (J2EE).
www.javaworld.com/channel_content/jw-patterns-index.shtml

Contm artigos que discutem quando utilizar e como implementar padres de projeto populares em Java, demonstrando-os com diagramas de classes da UML.
www.fluffycat.com/java/patterns.html

Fornece cdigo Java de exemplo e diagramas de classes da UML para ilustrar cada um dos 23 padres de projeto da Gang of Four.
www.cmcrossroads.com/bradapp/javapats.html

Discute os padres de projeto Java e padres de projeto presentes na computao distribuda.

www.javacamp.org/designPattern/

Fornece definies e cdigo de exemplo para vrios padres de projeto, descrevendo onde cada padro deve ser utilizado e seus benefcios.

Padres arquitetnicos
www.javaworld.com/javaworld/jw-04-1998/jw-04-howto.html

Contm um artigo sobre como os componentes Swing utilizam a arquitetura Model-View-Controller.

www.ootips.org/mvc-pattern.html

Fornece informaes e dicas sobre a utilizao do MVC.

www.tml.hut.fi/Opinnot/Tik-109.450/1998/niska/sld001.htm

Fornece informaes sobre o padro de projeto arquitetnico e idiomas (padres que tm por alvo um idioma especfico).