Padres de projeto em Programao OO

Hugo Gomes Arajo Departamento de Cincia da Computao Universidade Federal da Bahia (UFBa) Salvador, Ba Brasil hugomes@dcc.ufba.br Resumo. Esse artigo define e descreve o que so padres de projeto e os seus diversos tipos utilizados na engenharia de software. mostrado o funcionamento de alguns padres bem como sua classificao de acordo com o tipo de problema que eles solucionam. 1. Introduo Em geral, em engenharia de software, dois so os principais temas tratados: Metodologia para o desenvolvimento de sistemas e a Linguagem de modelagem para o projeto de software orientado a objetos. As dificuldades encontradas so decorrentes da falta de experincia de quem est aprendendo ambos os temas pela primeira vez ou da dificuldade de combinao de todos os elementos que fazem parte do projeto de um sistema complexo. Estudos de casos so uma fonte bastante rica para a soluo de problemas de projeto, mesmo para projetistas experientes. Um padro de projeto uma estrutura recorrente no projeto de software orientado a objetos. Pelo fato de ser recorrente, vale a pena que seja documentada e estudada. Podem ser definidos como uma soluo que j foi testada para um determinado problema. Desta forma, um padro de projeto geralmente descreve uma soluo ou uma instncia da soluo que foi utilizada para resolver um problema especfico. Estes Padres so solues para problemas que algum um dia teve e resolveu aplicando um modelo que foi documentado e que se pode adaptar integralmente ou de acordo com necessidade da soluo. 2. Histrico O conceito de padro de projeto foi criado na dcada de 70 pelo arquiteto Christopher Alexander. Em seus livros Notes on the Synthesis of Form, The Timeless Way of Building e A Pattern Language, ele estabelece caractersticas que um padro precisa possuir. Estas so: Encapsulamento, Generalidade, Equilbrio, Abstrao, Abertura e Combinatoriedade. Encapsulamento refere-se ao fato de que um padro deve encapsular um problema/soluo bem definida(o). Ele deve ser independente, especfico e formulado de maneira a ficar claro onde ele se aplica. Generalidade refere-se ao fato de que todo padro deve permitir a construo de outras realizaes a partir deste padro. Equilbrio refere-se ao fato de que

quando um padro utilizado em uma aplicao, o equilbrio d a razo, relacionada com cada uma das restries envolvidas, para cada passo do projeto. Uma anlise racional que envolva uma abstrao de dados empricos, uma observao da aplicao de padres em artefatos tradicionais, uma srie convincente de exemplos e uma anlise de solues ruins ou fracassadas pode ser a forma de encontrar este equilbrio. Abstrao necessria porque os padres devem representar abstraes da experincia emprica ou do conhecimento cotidiano. Abertura refere-se ao fato de que um padro deve permitir a sua extenso para nveis mais baixos de detalhe. Combinatoriedade refere-se ao fato de que os padres so relacionados hierarquicamente. Padres de alto nvel podem ser compostos ou relacionados com padres que endeream problemas de nvel mais baixo. Alm da definio das caractersticas de um padro, Alexander definiu o formato que a descrio de um padro deve ter. Essa descrio foi dividida em cinco partes e ser tratada na estrutura dos padres de projeto. Em 1987, a partir dos conceitos criados por Alexander, os programadores Kent Beck e Ward Cunningham propuseram os primeiros padres de projeto para a rea da cincia da computao. Em um trabalho para a conferncia OOPSLA, eles apresentaram alguns padres para a construo de janelas na linguagem Smalltalk. O tema padres de projeto ganhou popularidade com o livro Design Patterns: Elements of Reusable Object-Oriented Software, publicado em 1995. Os autores so Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, que ficaram conhecidos como a "Gangue dos Quatro" (Gang of Four) ou "GoF". Posteriormente, vrios outros livros do estilo foram publicados, como Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, que introduziu um conjunto de padres conhecidos como GRASP (General Responsibility Assignment Software Patterns).

3. Estrutura e classificao dos Padres de Projeto Um padro de projeto nomeia, abstrai e identifica os aspectos chave de uma estrutura de projeto comum para torn-la til para a criao de um projeto orientado a objetos reutilizvel. Os padres de projeto possuem atributos principais, necessrios para uma boa descrio que so: Nome: referncia que descreve de foram bastante sucinta o padro. Problema (motivao, inteno e objetivos, aplicabilidade): apresenta o contexto do padro e quando ele pode ser usado. Soluo (estrutura, participantes, exemplo de cdigo): descreve a soluo e os elementos que a compem.

Conseqncias e padres relacionados: analisa os resultados, vantagens e desvantagens obtidos com a aplicao do padro. Em geral os padres de projeto podem ser classificados em trs diferentes tipos e essas classificaes possuem subclassificaes. So classificados em Padres de criao, estruturais e comportamentais, e cada um desses tipos pode ser subclassificado em padres de classes e de objetos. 3.1 - Padres de Criao Os Padres de criao abstraem o processo de criao de objetos a partir da instanciao de classes. So estes: Abstract Factory: fornece uma interface para a criao de famlias de objetos relacionados ou dependentes sem especificar suas classes concretas. Seu uso pode ser verificado quando se necessria a transportabilidade entre diferentes bibliotecas de interfaces grficas (Gnome e KDE).

Figura 1 - Estrutura do funcionamento do padro Abstract Factory

Builder: separa a construo (geralmente passo a passo) de um objeto complexo da sua representao, de modo que o mesmo processo de construo possa criar diferentes representaes. Um uso conhecido desse tipo a converso de formatos de texto em editores.

Figura 2 - Estrutura do funcionamento do padro Builder

Factory Method: define uma interface para criar um objeto, mas deixa as subclasses decidirem qual classe ser instanciada. Permite a uma classe postergar a instanciao de subclasses. Esse tipo bastante usado em toolkits e frameworks para a instanciao de objetos. Prototype: especifica os tipos de objetos a serem criados usando uma instncia prototpica e cria novos objetos copiando este prottipo. O depurador Etgdb utiliza esse padro. Singleton: garante que uma classe tenha somente uma instncia e fornece um ponto global de acesso para ela. Esse padro verificado em programas que s podem ter uma instncia sendo executada em um dado momento. 3.2 Padres estruturais Esses padres visam tratar da forma como classes e objetos esto organizados para a formao de estruturas maiores. Adapter: converte a interface de uma classe em outra interface esperada pelos clientes. Permite que certas classes trabalhem em conjunto, pois de outra forma seria impossvel por causa de suas interfaces incompatveis. Um uso conhecido desse tipo popularmente conhecido como wrapper, usado para adaptar a interface de classes.

Figura 3 - Estrutura do funcionamento do padro adapter

Bridge: separa uma abstrao da sua implementao, de modo que as duas possam variar independentemente. Esse tipo usado para evitar o vnculo entre abstrao e implementao quando h mudanas na implementao em tempo de execuo. Composite: compe objetos em estrutura de rvore para representar hierarquias do tipo partes-todo. Permite que os clientes da estrutura tratem objetos individuais e composies de objetos de maneira uniforme. usado para representar hierarquias partes-todo.

Figura 4 - Estrutura do funcionamento do padro Composite

Decorator: atribui responsabilidades adicionais a um objeto dinamicamente. Fornece uma alternativa flexvel utilizao de subclasses para a extenso de funcionalidades. utilizado na atribuio de enfeites grficos e outras funcionalidades acessrias a widgets. Faade: fornece uma interface unificada para um conjunto de interfaces em um subsistema. Define uma interface de nvel mais alto que torna o subsistema mais fcil de usar. Um uso conhecido quando h interface nica em sistemas complexos.

Figura 5 - Estrutura do funcionamento do padro Faade

Flyweight: usa compartilhamento para suportar grandes quantidades de objetos, de granularidade fina, de maneira eficiente. utilizado em sistemas com grande nmero de objetos. Proxy: fornece um objeto representante ou um marcador de outro objeto para controlar o acesso ao mesmo. Algumas implementaes de CORBA utilizam esse padro

Figura 6 - Estrutura do funcionamento do padro Proxy

3.3 Padres Comportamentais Esses padres preocupam-se com algoritmos e a atribuio de responsabilidade entre objetos. Chain of Responsibility: evita o acoplamento entre o remetente de uma solicitao e o destinatrio da solicitao, dando a mais de um objeto a chance de tratar a solicitao. Encadeia os objetos receptores e passa a solicitao ao longo da cadeia at que um objeto a trate. Utilizado quando necessrio fazer tratamento de eventos de usurio.

Figura 7 - Estrutura do funcionamento do padro Chain of Responsibility

Command: encapsula uma solicitao como um objeto, permitindo a parametrizao de clientes com diferentes solicitaes, o enfileiramento e o registro de solicitaes e o suporte a operaes que possam ser, por exemplo, desfeitas. Uma utilizao conhecida desse padro o suporte operao desfazer.

Figura 8 - Estrutura do funcionamento do padro Command

Interpreter: dada uma linguagem, define uma representao para sua gramtica juntamente com um interpretador que usa a representao para interpretar sentenas nesta linguagem. Pode ser utilizado quando se necessrio interpretar uma linguagem com uma

rvore sinttica abstrata, como em compiladores de linguagens orientadas a objetos. Iterator: fornece uma maneira de acessar seqencialmente os elementos de um objeto agregado sem expor sua representao subjacente. Usado na C++ Standard Template Library. Mediator: define um objeto que encapsula a interao entre um conjunto de objetos. Promove o acoplamento fraco ao evitar que os objetos se refiram explicitamente uns aos outros, permitindo a variao das interaes independentemente. Uma utilizao conhecida na arquitetura de aplicaes de Smalltalk. Memento: sem violar a encapsulao, captura e externaliza um estado interno de um objeto, de modo que o mesmo possa posteriormente ser restaurado para este estado. Utilizado quando se necessita fazer um armazenamento instantneo do estado do objeto sem romper sua encapsulao. Observer: define uma dependncia um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes so automaticamente notificados e atualizados. Utilizado na propagao de mudanas e atualizaes com acoplamento fraco entre os objetos.

Figura 9 - Estrutura do funcionamento do padro Observer

State: permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecer ter mudado sua classe. utilizado em algumas implementaes da pilha TCP/IP.

Figura 10 - Estrutura do funcionamento do padro State

Strategy: define uma famlia de algoritmos, encapsula cada um deles e os faz intercambiveis. Permite que o algoritmo varie independentemente dos clientes que o utilizam. Usado em sistemas de otimizao.

Figura 11 - Estrutura do funcionamento do padro Strategy

Template Method: define o esqueleto de um algoritmo em uma operao, postergando a definio de alguns passos para subclasses. Permite que as subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura. Uso conhecido: arquiteturas Application/Document/View.

Figura 12 - Estrutura do funcionamento do padro Template Method

Visitor: representa uma operao a ser executada sobre os elementos de uma estrutura de objetos. Permite a definio de uma nova operao sem mudar as classes dos elementos sobre os quais opera. Usado para executar uma srie de operaes sobre objetos que possuem interfaces diferentes, sem poluir a interface dos mesmos.

4. Seleo dos padres para utilizao Para selecionar um padro de projeto a ser utilizado devemos considerar alguns fatores. Primeiramente deve ser levado em considerao como os padres de projeto solucionam os problemas do projeto. Deve-se examinar as sees de descrio do problema de cada padro. O conhecimento dos padres tambm importante pois com isso sabe-se como os padres se interrelacionam. Os diversos padres de um mesmo tipo possuem finalidades semelhantes, ento interessante que se escolha um padro pelo problema que ele resolve. Como existem vrios de um mesmo tipo com diferenas pequenas, o estudo aprofundado determinar qual se aplica da melhor maneira. Deve-se ainda examinar uma causa de reformulao de projeto e considerar o que pode ser varivel no projeto. 5. Concluso Os padres de projeto so solues que foram testadas e comprovadas o seu funcionamento. Em diversos casos torna o projeto mais simples, desde que se aplique o padro certo de acordo com a necessidade. Isso ser avaliado pelo nvel de conhecimento, relacionado aos padres de projeto, que o engenheiro de software possui. Com o aparecimento dos padres pode-se haver questionamentos quanto ao surgimento de novas solues para problemas antigos (ou novos). Como j existem padres testados, os engenheiros de softwares se tornariam acomodados e o desenvolvimento e aparecimento de novos padres no ocorreria. claro que questes como essas so bem pessoais. O uso de padres ou no, depende nico e exclusivamente do engenheiro de software. Ele ir decidir se prefere quebrar a cabea para tentar uma nova soluo, ou se prefere se utilizar de outra soluo que j comprovado o seu funcionamento. Acredito que a utilizao dos padres faa com que apaream questionamentos e tentativas de um melhoramento nas solues (padres j existentes) que so tidas como timas, por serem testadas e utilizadas por grande quantidade de arquitetos/engenheiros de software.

Referncias: 1 Padres de Projeto: Solues Reutilizveis de Software Orientado a Objetos -- The Gang of Four.. 2 www.google.com