UNIVERSIDADE FEDERAL FLUMINENSE MESTRADO EM COMPUTAO 2003.

DESIGN PATTERNS PADRES PARA PROJETOS

LUIS VALENTE

ENGENHARIA DE SOFTWARE PROF. MARIA LUIZA SANCHEZ

Lista de Figuras
Figura 1: Ciclo de vida de um padro ......................................................................................................4 Figura 2: Padro Singleton ...................................................................................................................... 8 Figura 3: Padro Factory Method ............................................................................................................8 Figura 4: Exemplo de uma fachada ......................................................................................................... 9 Figura 5: Possvel estrutura para um sistema de compilao ................................................................ 10 Figura 6: Padro Template Method em um framework ........................................................................ 11

Lista de Tabelas
Tabela 1: Classificao de padres por [GOF95] ................................................................................. 12 Tabela 2: Classificao de padres por [JPW02] ..................................................................................13

ii

ndice
1. Introduo............................................................................................................................................. 1 2. Histria................................................................................................................................................. 1 3. Definio...............................................................................................................................................1 4. Motivaes............................................................................................................................................3 5. Descobrimento de padres....................................................................................................................3 6. Especificao formal............................................................................................................................ 4 7. Design Patterns..................................................................................................................................... 5 8. Anti-Patterns......................................................................................................................................... 6 9. Frameworks.......................................................................................................................................... 7 10. Exemplos............................................................................................................................................ 7 10.1. Creational Patterns..................................................................................................................... 7 10.1.1. Singleton.............................................................................................................................8 10.1.2. Factory Method.................................................................................................................. 8 10.2. Structural Patterns...................................................................................................................... 9 10.2.1. Faade.................................................................................................................................9 10.3. Behavioral Patterns...................................................................................................................10 10.3.1. Template Method............................................................................................................. 10 11. Concluso......................................................................................................................................... 11 12. Anexo 1: Classificao de Design Patterns...................................................................................... 12 12.1. Vertentes...................................................................................................................................12 13. Anexo 2: Resumo dos Design Patterns Clssicos............................................................................ 14 14. Anexo 3: Resumo dos padres GRASP........................................................................................... 16 15. Referncias....................................................................................................................................... 18

iii

1. Introduo
Este trabalho descreve uma introduo ao conceito de padres de software. So apresentadas definies, motivaes para o uso de padres, mtodos de descobrimento e descrio de padres, design patterns, anti-patterns e comparao entre padres e frameworks. Na seo Exemplos, so demonstrados alguns dos design patterns definidos originalmente por [GOF95]. No Anexo 1, so discutidas algumas das diversas classificaes existentes para os design patterns. Um resumo dos design patterns definidos por [GOF95] apresentado no Anexo 2. Os padres GRASP, definidos em [AUP01], so descritos resumidamente no Anexo 3.

2. Histria
O desenvolvimento dos padres de software teve como inspirao os trabalhos do arquiteto Christopher Alexander. O significado atual de pattern foi utilizado inicialmente por Chistopher Alexander para planejamento urbano e projetos de Arquitetura em vrios livros publicados nas dcadas de 60 e 70:

Notes on the Synthesis of Form, Havard University Press, 1964; The Oregon Experiment, Oxford University Press, 1975; A Pattern Language: Towns, Buildings, Constructions, Oxford University Press, 1977; The Timeless Way of Thinking, Oxford University Press, 1979.

Em 1987, Kent Beck e Ward Cunningham utilizaram as idias de Christopher Alexander para desenvolver um pequeno conjunto de padres para serem usados na linguagem de programao Smalltalk. O resultado desse trabalho foi descrito no artigo Using pattern languages for object-oriented programs, apresentado na OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications) daquele ano. No incio da dcada de 90, Erich Gamma utilizou padres em sua tese de doutorado, um projeto orientado a objetos para aplicaes com interface grfica. Em 1991, Erich Gamma e Richard Helm iniciaram um catlogo de padres um pouco antes da ECOOP '91 (European Conference for Object-Oriented Programming). Em conferncias posteriores, Erich Gamma e Richard Helm encontraram Ralph Johnson e John Vlissides, que mais tarde viriam a formar a chamada guangue dos quatro (Gang of Four). A guangue dos quatro responsvel pelo livro mais famoso relacionado a padres, Design Patterns: Elements of Reusable Object-Oriented Software. Esse livro, publicado em 1995, foi um dos primeiros a descrever e apresentar um catlogo de design patterns, contendo vinte e trs padres.

3. Definio
Os padres descrevem solues para problemas que ocorrem repetidamente em sistemas diversos. Essas solues so descritas de forma que possam ser reutilizadas em vrios sistemas diferentes. Um padro, alm de apresentar uma soluo para um determinado problema, indica o contexto necessrio para a sua aplicao e explica porque a soluo bem sucedida. Um padro tambm pode ser visto como uma formalidade utilizada para registrar o conhecimento e a experincia dos modeladores mais experientes, para transmit-los aos iniciantes e como uma forma de documentao.
1

Os padres podem ser utilizados em diversas reas da indstria de software, como algumas descritas a seguir:

Padres de anlise (Analisys Patterns) Padres que ocorrem durante uma fase de anlise, por exemplo, regras bancrias. Padres de processos (Process Patterns) Padres relacionados a processos de desenvolvimento de software, por exemplo, regras e passos de projeto e anlise orientada a objeto.

Padres empresariais (Organizational Patterns) Padres relacionados com o funcionamento de empresas ou corporaes, por exemplo, estruturao de equipes de desenvolvimento.

Outros exemplos onde padres so utilizados Planejamento de projetos, frameworks, arquitetura de sistemas, etc.

Um padro descrito essencialmente pelos seguintes elementos:

Nome Um identificador que qualifica a idia geral do padro, o problema a ser resolvido, a soluo e consequncias em uma nica expresso. O uso de nomes bem definidos tambm ajuda no desenvolvimento de uma cultura sobre padres.

Problema Descreve os apectos essenciais que caracterizam o problema a ser resolvido. descrito, tambm, o contexto onde o padro pode ser aplicado. O contexto inclui as pr-condies e restries (por exemplo, uma interao entre dois componentes do sistema deve ser implementada utilizando um determinado protocolo de comunicao). O contexto tambm explica as razes da ocorrncia do problema, quando e como este se manifesta.

Soluo Demonstra como resolver o problema, ou como equilibrar todas as restries e prcondies especificadas da melhor maneira. A soluo pode ser composta por duas partes. Uma parte descreve uma estrutura esttica da soluo. Essa estrutura esttica define os componentes (objetos, classes ou outras entidades) participantes, suas responsabilidades e relacionamentos. A outra parte descreve uma estrutura dinmica, que consiste na especificao de colaboraes e interaes entre os participantes da soluo. interessante observar que a soluo pode no resolver todas as restries ou prcondies do problema, principalmente se elas forem contraditrias. A soluo descrita no representa uma resposta concreta, mas apenas um esquema onde os aspectos esseciais so evidenciados.

Consequncias Descrevem os e resultados e custos da aplicao do padro. As consequncias tambm podem indicar o impacto do uso do padro na estabilidade e extensibilidade do sistema, por exemplo.

interessante notar que existem padres usados somente em domnios especficos, como padres para sistemas em tempo real, padres para sistemas de banco de dados, entre outros.

4. Motivaes
Existem vrias motivaes para se utilizar padres de software, entre as quais podem ser citadas:

Padres resolvem problemas reais, sendo solues j comprovadas e testadas em diversos casos de um ou vrios domnios; Capturam o conhecimento dos modeladores mais experientes, aumentando o reuso de idias; Ajudam modeladores iniciantes a compreender e resolver problemas complexos; Podem ser utilizados para registrar e encorajar o reuso das melhores prticas; Capturam partes essenciais do projeto de forma compacta; Aumentam o nvel de abstrao para o desenvolvimento de solues para os problemas; Formam um vocabulrio comum para discusso e resoluo de problemas; Servem para melhorar a comunicao entre membros de uma equipe; Alm da soluo, indicam as condies necessrias para aplic-la, o raciocnio lgico utilizado para conceb-la, as restries e custos associados.

5. Descobrimento de padres
Um modelo, para ser considerado um padro, deve ser um fenmeno recorrente. Existe uma conveno, definida em como rule of three, que indica que um determinado modelo deve ocorrer em pelo menos trs sistemas diferentes para ser considerada um padro. Segundo [PSECT00], outros critrios utilizados para se definir um padro esto entre os seguintes:

Um padro resolve problemas, ou seja, descrevem solues e no estratgias ou princpios abstratos; Um padro representa um conceito provado na prtica (no teoria nem especulao); Um padro descreve uma soluo que no aparentemente bvia; Um padro explica porque a soluo apresentada til e funcional.

Outros autores, como em [POAD03], definem um ciclo de vida para um padro, da seguinte forma:

Fase 1: Minerao Nesta fase, feita a documentao inicial do padro. Autores experientes, trabalhando em projetos prticos, podem vir a descobrir (e documentar) novos padres. O autor do padro deve decidir o que faz parte do padro e em qual domnio aplicvel. A chamada rule of three pode ser usada para decidir sobre a validade do padro.

Fase 2: Refinamento Nesta fase, o padro avaliado por pesquisadores e outros modeladores experientes. O objetivo ajudar o autor a melhorar a verso inicial do padro ou, se for o caso, a abandon-lo caso este seja invivel. O padro pode, eventualmente, vir a ser apresentado em conferncias sobre o assunto (como as conferncias Pattern Language of Programs). O resultado desta fase um padro bem documentado e pronto pra reuso.

Fase 3: Reuso Nesta fase, ocorre o reuso propriamente dito. Usurios procuram por padres em catlogos e livros. Os padres, ento, so utilizados em projetos reais. Os usurios podem enviar ao autor sugestes e crticas a respeito de suas experincias com o padro, o que contribui para o seu aperfeiamento.

O ciclo de vida anterior ilustrado na seguinte figura, presente em [POAD03]:

Figura 1: Ciclo de vida de um padro

6. Especificao formal
Existem diversos formatos utilizados para se definir um padro. Entretanto, um formato possui os seguintes elementos, comumente:

Nome Um bom nome para um padro aquele que reflete a sua estrutura e funo. Um mesmo padro pode ter outros nomes ou apelidos. Nesse caso, comum que estes nomes alternativos tambm sejam documentados.

Propsito Descreve o problema a ser resolvido e dos objetivos a serem alcanados.

Motivao Explica como e onde o problema ocorre, e porque o padro pode resolv-lo. Aplicabilidade Descreve as pr-condies necessrias para a utilizao do padro. Restries e custos associados com o problema tambm podem ser especificados. Tambm conhecido como Contexto inicial.

Estrutura Apresenta um modelo, em uma linguagem como UML, das classes participantes. Podem ser utilizados outros diagramas, como diagramas de sequncia ou de colaborao.

Soluo Especifica os participantes da soluo, sua estrutura, colaboraes entre os participantes, responsabilidades e seus relacionamentos. Descreve os passos necessrios para complet-la. Adicionalmente, pode descrever aes a serem evitadas.

Consequncias Descreve ps-condies, resultados e efeitos colaterais ocasionados pela aplicao do padro. Tambm conhecido como Contexto resultante.

Razes lgicas Justificam a soluo, explicando porque o padro aplicvel e porque a alternativa apresentada uma boa soluo.

Padres relacionados Padres que so similares ou que podem ser aplicados anteriormente ou posteriormente ao padro em questo. Por exemplo, um determinado padro poderia ser aplicado de forma que o contexto resultante resultasse no contexto inicial de um outro padro.

Casos conhecidos Descreve aplicaes do padro em sistemas diferentes. Estes casos ajudam a validar o padro (recorrncia) e servem como exemplos instrutivos.

7. Design Patterns
Design Patterns so padres que ocorrem em fases de projeto. A noo original de design patterns foi definida em [GOF95] da seguinte forma:
Um design pattern abstrai e indentifica os aspectos essenciais de uma estrutura de modo que esta possa ser usada para criar um projeto orientado a objetos reutilizvel. O design pattern identifica as classes participantes, seus papis e colaboraes, assim como a distribuio de responsabilidades. Cada design pattern est relacionado com um determinado tipo de problema de projeto orientado a objetos. O design pattern descreve quando possvel aplic-lo, se possvel ou no aplic-lo em virtude de outras restries de projeto, e os custos e consequncias resultantes de sua aplicao. Como eventualmente o projeto dever ser implementado, um design pattern pode utilizar algum cdigo fonte pra ilustrar uma implementao.

A definio proposta em [GOF95] essencialmente orientada a objetos. Um design pattern orientado a objetos pode utilizar uma linguagem como UML para apresentar diagramas1 de classes e objetos que compem o padro.
1 Qualquer tipo de diagrama, como diagramas de classes, sequncia e colaboraes.

Os design patterns provm um esquema para um refinamento de subsistemas ou componentes de um sistema de software. Estes tipos de padres definem uma microarquitetura, sendo que sua influncia restringe-se regio do sistema onde so utilizados. Os design patterns propostos por [GOF95] so classificados nas seguintes categorias:

Padres de criao (Creational Patterns) Especificam o processo de criao de objetos. Podem abstrair os detalhes de criao para que a implementao seja independente dos tipos de objetos envolvidos. Desta forma, ao se adicionar um novo tipo de objeto queles que podem ser criados, no ser necessrio promover grandes mudanas no cdigo.

Padres estruturais (Structural Patterns) Lidam com as conexes ou relacionamentos entre objetos, ou seja, especificam composies de objetos ou classes.

Padres comportamentais (Behavioral Patterns) Caracterizam interaes de objetos entre si, ou seja, controlam determinados tipos de aes no sistema e distribuem responsabilidades.

Existem vrias classificaes de design patterns, concebidas sob diferentes abrordagens. Um detalhamento sobre as classificaes encontra-se em anexo. Outros autores, como em [POSA96], definem outros tipos de padres relacionados com design patterns, com nveis de abstrao diferentes:

Architectural Patterns Provm uma representao estrutural para um sistema de software. So padres de alto nvel, com efeitos globais sobre todo sistema. Podem ser utilizados para implementao de frameworks. Exemplo: MVC (Model-View-Controler).

Idioms Representam padres de baixo nvel, especficos de uma determinada linguagem de programao. Um idiom descreve como implementar um determinado componente utilizando as ferramentas oferecidas pela linguagem de programao. Possuem o menor nvel de abstrao.

A diferena principal entre esses tipos de padres est no escopo e nvel de detalhe. Os design patterns possuem nvel de abstrao intermedirio entre os outros dois tipos de padres citados.

8. Anti-Patterns
Se os padres de software indicam boas solues para determinados problemas, um antipattern indica uma soluo ruim para um dado problema [C2WIKI03]. Existem duas noes para um anti-patterns, segundo [PSECT00]:

Aqueles que descrevem uma soluo ruim para um dado problema; Aqueles que indicam como se recuperar de complicaes causadas por solues ruins e como proceder para resolver o problema original a partir desse ponto.

Segundo [C2WIKI03], um bom anti-pattern explica as razes pelas quais uma soluo ruim aparenta ser atraente, porque ela ruim e que outros padres regulares (positivos) podem ser aplicados para solucionar o problema original.

Existem outros nomes para identificar este tipo de padro, como amelioration pattern, dark pattern e grey pattern.

9. Frameworks
Frameworks so definidos em [PSECT00] da seguinte forma:
Um framework uma mini-arquitetura reusvel que prov estrutura e comportamento genricos para uma famlia de sistemas.

Um framework, desta forma, prov um ponto de partida para o desenvolvimento de um sistema. Ao desenvolvedor, cabe a tarefa de especificar funcionalidades especficas de sua aplicao em partes especficas do framework (os chamados hot spots). Um framework de software orientado a objetos, definido em [GOF95] como a seguir:
Um framework um conjunto de classes que cooperam entre si para formar um projeto especfico para um tipo de sistema. Um framework fornece um esqueleto do sistema ao dividir o projeto em classes abstratas, definindo suas responsabilidades e colaboraes. Um desenvolvedor concretiza uma determinada aplicao por herana e composio de instncias de classes do framework.

possvel citar algumas diferenas entre frameworks e padres:

Os frameworks determinam a arquitetura de um sistema, enquanto os padres definem microarquiteturas (ou seja, influenciam apenas uma determinada parte da aplicao). Desta forma, um framework pode utilizar vrios padres para especificar a sua arquitetura. Alteraes em um framework implicam em efeitos sobre a arquitetura do sistema, enquanto que alteraes introduzidas por padres possuem efeitos locais. Frameworks podem ser reutilizados imediatamente (j esto escritos em uma determinada linguagem de programao), enquanto os padres precisam ser implementados. Frameworks so escritos para um determinado tipo de aplicao (domnio) e, por essa razo, so mais especializados do que os padres.

Exemplos de frameworks incluem Java Foundation Classes (JFC), Java AWT, Java Swing, Enterprise Java Beans (EJB), Microsoft Foundation Classes (MFC), Commom Object Request Broker Architecture (CORBA), Visual Component Library2 (VCL), entre outros.

10. Exemplos
Nesta seo, so apresentados alguns exemplos de padres de acordo com as classificaes definidas em [GOF95].

10.1. Creational Patterns

Os padres definidos em [GOF95] como padres de criao so: Abstract Factory, Builder, Factory Method, Prototype e Singleton. Esta seo exmplifica os padres Singleton e Factory Method.

2 Usada em Borland Delphi e Borland C++ Builder.

10.1.1. Singleton
O Singleton, possivelmente, o design pattern mais simples de todos. Basicamente, sua funo garantir que exista apenas uma nica instncia de uma determinada classe.

Figura 2: Padro Singleton

O acesso instncia da classe feito atravs de uma nica operao. Desta forma, possvel ter um controle rgido sobre o acesso ao recurso. Adicionalmente, o Singleton pode ser extendido para oferecer acesso a um determinado nmero de instncias de uma classe como, por exemplo, um certo nmero de conexes a um banco de dados (connection pool).

10.1.2. Factory Method

O padro Factory Method permite que se crie uma interface comum para uma famlia de objetos. Esta caracterstica faz com que a responsabilidade de se criar os objetos concretos seja transferida para as classes derivadas. Este padro til quando no possvel saber inicialmente que tipos de objetos sero criados na aplicao. Por exemplo, pode-se construir uma fbrica de formas geomtricas conforme a seguinte figura:

Figura 3: Padro Factory Method

Para acrescentar novos tipos de formas geomtricas, necessrio apenas adicionar o novo tipo fbrica. Desta forma, o processo de instanciamento de objetos centralizado. preciso observar, entretanto, que ao adicionar um novo tipo, ser necessrio implementar a classe relacionada em alguma parte do sistema. Em resumo, algumas vantagens de se utilizar esse padro:

O cliente no necessita conhecer os detalhes da criao de um objeto; A forma de criao de um objeto concreto isolada. Desta forma, possvel efetuar alteraes no modo de criao do objeto sem afetar o cliente; Novas classes da mesma famlia podem ser adicionadas sem causar efeitos colaterais no sistema, ou seja, a extensibilidade aumentada.

10.2. Structural Patterns

Os padres definidos em [GOF95] como padres estruturais so: Adapter, Bridge, Composite, Decorator, Faade e Proxy. Esta seo exemplifica o padro Faade.

10.2.1. Faade
O padro Faade (fachada) utilizado para se reduzir a complexidade de um sistema. O objetivo oferecer uma interface nica de modo a diminuir dependncias e comunicaes entre subsistemas. Este esquema pode ser visualizado da seguinte forma:

Figura 4: Exemplo de uma fachada

O uso da fachada, por ser centralizador, diminui os efeitos causados por alteraes em determinadas partes do sistema. Em [GOF95], descrito um exemplo concreto para um compilador, cuja estrutura descrita a seguir:

Figura 5: Possvel estrutura para um sistema de compilao

Um compilador possui vrios subsistemas com funes especficas, como o scanner, o parser, o gerador de cdigo, entre outros. Normalmente, usurios deste tipo de sistema se interessam apenas pelo produto final, que o cdigo compilado. Desta forma, ao definir uma classe com uma operao que centraliza o processo de compilao (i.e. a fachada), o usurio no obrigado a conhecer os detalhes da implementao. Por exemplo, se fosse necessrio adicionar alguma operao ao processo de compilao, isso seria feito diretamente na fachada. Caso a fachada no fosse implementada, seria necessrio fazer a alterao em todas as partes do sistema onde o processo de compilao fosse utilizado. Desta forma, a fachada diminui a complexidade do sistema. importante observar que o uso da fachada no impede que os usurios acessem os subsistemas individualmente.

10.3. Behavioral Patterns

Os padres comportamentais definidos em [GOF95] so os seguintes: Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Flyweight, Observer, State, Strategy, Template Method e Visitor. Esta seo exemplifica o padro Template Method.

10.3.1. Template Method

O padro Template Method pode ser utilizado para a construo de frameworks. Ele tambm poderia ser considerado um padro estrutural porque define uma estrutura inicial (esqueleto) para um determinado algoritmo ou tarefa. Por exemplo, um jogo de computador uma aplicao que, basicamente, implementa um lao de execuo do tipo: 1. Recupera dados de entrada do usurio (input);
10

2. Atualiza o estado da aplicao, baseado nos dados de entrada; 3. Desenha os resultados na tela (render); 4. Voltar para 1. possvel definir um framework inicial para jogos da seguinte forma:

Figura 6: Padro Template Method em um framework

A classe base Game implementa o lao de execuo (a operao run ) de maneira fixa, enquanto as classes derivadas implementam as funcionalidades especficas (getInput, update e render). Esse padro est relacionado com outros padres como o State, que define classes para representar estados de uma aplicao. Nesse caso, cada classe representaria uma fase de jogo (ou seja, cada fase seria um estado diferente), sendo que todas elas utilizariam o Template Method para definir a funcionalidade (ou sejam, todas elas utilizariam o framework).

11. Concluso
Os padres descrevem solues para problemas que ocorrem repetidamente em sistemas diversos. Padres de software esto presentes em diversas reas da indstria, como padres de anlise, padres organizacionais, padres de processos, entre outras. Padres representam o conhecimento de projetistas experientes, sendo descobertos em vrios sistemas diversos. Desta forma, padres resolvem problemas reais (ou seja, no so inventados). Um padro descrito essencialmente por seu nome, o problema a ser resolvido (contextualizao, desafios), a soluo (passos necessrios e justificativas) e as consequncias (efeitos ocasionados pela aplicao do padro, bons e ruins). Os design patterns so padres que ocorrem em fase de projeto. Este tipo de padro foi especificado inicialmente por [GOF95]. Os padres definidos em [GOF95] so, essencialmente, orientados a objetos. Existem diversas classificaes para os padres, mas todas elas seguem critrios subjetivos e qualitativos.

11

12. Anexo 1: Classificao de Design Patterns

Este anexo ilustra algumas das diferentes vises a respeito da classificao dos design patterns. Algumas classificaes definem categorias cujos elementos podem pertencer a vrias delas ao mesmo tempo. Outras classificaes propem critrios mais refinados. O objetivo no determinar se uma classificao mais correta que a outra, mas compreender como as alternativas propostas podem ser teis. importante observar que as classificaes de padres seguem critrios subjetivos.

12.1. Vertentes
A classificao proposta por [GOF95] organiza seus elementos segundo dois critrios:

Escopo O critrio de escopo especifica se um padro aplicvel a classes ou instncias. Um padro aplicvel a classes determina relaes entre classes e subclasses, ou seja, definido atravs de herana. Este tipo de relao fixo (esttico). Os padres aplicveis a instncias de classes definem relaes entre objetos que podem ser alteradas dinamicamente.

Propsito (funo) O critrio por propsito define as categorias Padres de Criao (Creational Patterns), Padres Estruturais (Structural Patterns) e Padres Comportamentais (Behavioral Patterns). Este o critrio mais utilizado.

Propsito Criao Escopo Classe Factory Method Objeto Abstract Factory Builder Prototype Singleton Estruturais Adapter Adapter Bridge Composite Decorator Facade Proxy Comportamentais Interpreter Template Method Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor

Tabela 1: Classificao de padres por [GOF95]

Outros autores, como em [JPW02], organizam o mesmo catlogo definido em [GOF95] segundo intenes (problemas a serem resolvidos):

12

Inteno Oferecer uma interface Designar uma responsabilidade Construir classes ou objetos Controlar operaes Implementar extenses
Tabela 2: Classificao de padres por [JPW02]

Padro Adapter, Faade, Composite, Bridge Singleton, Observer, Mediator, Proxy, Chain of responsibility, Flyweight Builder, Factory Method, Abstract Factory, Prototype, Memento Template Method, Strategy, State, Command, Interpreter Decorator, Iterator, Visitor

Em [AUP01], definida uma outra classificao inteiramente baseada na designao de responsabilidades. Tal classificao denominada GRASP (General Responsibility Assignment Software Patterns). Responsabilidade definida em [AUP01] como sendo uma obrigao de um objeto em termos de seu comportamento. Os tipos de responsabilidades definidos so:

Conhecer Conhecimento sobre dados privados encapsulados; Conhecimento sobre objetos relacionados; Conhecimento sobre dados que possam ser calculados ou deduzidos. Fazer Controlar ou coordenar atividades de outros objetos; Iniciar aes em outros objetos; Realizar alguma tarefa por si prprio, como criar outros objetos ou efetuar clculos.

Designar responsabilidades uma tarefa crucial no desenvolvimento de um sistema, pois uma distribuio de responsabilidades ruim pode levar sistemas frgeis e difceis de serem compreendidos, com manuteno e reuso prejudicados. Embora as classificaes utilizem um enfoque diferente, possvel identificar algumas partes comuns. Por exemplo, em [AUP01], definido um padro denominado Controller que possui caractersticas semelhantes ao padro Faade definido em [GOF95]. O Faade considerado estrutural em [GOF95] porque define uma interface que envolve uma determinada parte do sistema ou subsistema (ou seja, cria uma nova estrutura no sistema). Em [AUP01], possvel encontrar a seguinte recomendao sobre o padro Controller:
Designar a responsabilidade de receber ou tratar um evento de sistema para uma classe que represente uma das seguintes escolhas:

Representa o sistema, dispositivo ou subsistema;

...

Desta forma, possvel observar que os propsitos de Controller e Faade so parecidos, embora sejam enquadrados em categorias de classificaes diferentes. Conclui-se, ento, que a classificao de padres segue critrios subjetivos, no existindo um conveno nica ou formal. A diferena principal a abordagem utilizada.
13

13. Anexo 2: Resumo dos Design Patterns Clssicos

Este anexo apresenta um resumo dos problemas a serem resolvidos pelos design patterns propostos por [GOF95], segundo os prprios autores. Abstract Factory Prover uma interface para se criar famlias de objetos relacionados ou dependentes sem especificar suas classes concretas. Adapter Converter a interface de uma classe em outra interface esperada pelos clientes. Adapter permite a comunicao entre classes que no poderiam trabalhar juntas devido incompatibilidade de suas interfaces. Bridge Desacoplar uma abstrao de sua implementao para permitir que ambos variem independentemente. Builder Separar a construo de um objeto complexo de sua representao para que o mesmo processo de construo possa criar diferentes representaes. Chain of Responsability Evita acoplar o remetente de uma requisio ao seu destinatrio ao permitir que mais de um objeto trate a requisio. Compe os objetos em cascata e passa a requisio adiante at que um objeto a trate. Command Encapsular uma requisio como um objeto, permitindo que clientes parametrizem diferentes tipos de requisies. Composite Compor objetos em estruturas de rvore para representar hierarquias parcialmente completas. Composite permite que clientes tratem objetos individuais e composies de objetos de maneira uniforme. Decorator Anexar responsabilidades adicionais a um objeto dinamicamente. Decorators oferecem uma outra alternativa ao uso de herana para estender uma funcionalidade. Faade Oferecer uma interface nica para um conjunto de interfaces de um subsistema. Faade define uma interface de nvel mais elevado que reduz a complexidade do subsistema. Factory Method Definir uma interface para criar um objeto, mas permitir que as subclasses decidam o tipo da classe a ser instanciada. Factory Method permite que uma classe delegue a responsabilidade de instanciamento s subclasses.

14

Flyweight Usar compartilhamento para tratar grandes quantidades de objetos refinados de maneira eficiente. Interpreter Dada uma linguagem, definir uma representao para sua gramtica e um interpretador que utiliza essa representao para interpretar sentenas na linguagem. Iterator Prover uma alternativa para acessar os elementos de um objeto agregado seqencialmente, sem expor sua representao interna. Mediator Definir um objeto que encapsula a forma como um conjunto de objetos interage entre si. Mediator promove acoplamento fraco ao evitar que os objetos se refiram uns aos outros explicitamente, permitindo que a interao desses objetos de seja alterada de maneira independente. Memento Capturar e exteriorizar o estado interno de uma objeto, sem violar o encapsulamento, para que seja possvel restaurar o estado interno desse objeto posteriormente. Observer Definir uma dependncia um-para-muitos entre objetos de modo que quando um objeto mudar de estado, todos os seus dependentes sejam notificados e atualizados automaticamente. Prototype Especificar os tipos de objetos a serem criados usando uma instncia como prottipo, e criar novos objetos ao copiar este prottipo. Proxy Prover um substituto ou ponto atravs do qual um objeto possa controlar o acesso a outro objeto. Singleton Garantir que uma classe s tenha uma nica instncia, e prover um ponto de acesso global a ela. State Permitir a um objeto alterar o seu comportamento quando o seu estado interno mudar. O objeto aparentar ter trocado de classe. Strategy Definir uma famlia de algoritmos, encapsular cada um, e torn-los intercambiveis. Strategy permite que os algoritmos sejam trocados independentemente pelos clientes que os utilizam.

15

Template Method Definir o esqueleto de um algoritmo, para que as subclasses possam prover especialidade especfica posteiormente. Template Method permite que suas subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura. Visitor Representar uma operao a ser realizada sobre os elementos de uma estrutura de objetos. Visitor permite definir uma nova operao sem alterar as classes dos elementos envolvidos.

14. Anexo 3: Resumo dos padres GRASP

Este anexo apresenta um resumo dos padres GRASP (General Responsibility Assignment Software Patterns), definidos por Craig Larman em [AUP01]. Information Expert o caso mais genrico de atribuio de responsabilidades. Atribuir a responsabilidade ao especialista (expert) a classe que possui todas as informaes necessrias para arcar com a responsabilidade. Creator Lida com a criao de objetos. Atribuir classe B a responsabilidade de se criar uma instncia da classe A se B contiver A de alguma maneira (agregrao, por exemplo) ou possuir dados necessrios (ou requeridos) para criar uma instncia de A. Controller Lida com o tratamento de mensagens ou eventos de sistema. Atribuir a responsabilidade de tratar eventos do sistema a uma classe que represente uma das seguintes opes:

Representa o sistema como um todo, um dispositivo ou um subsistema (um controlador fachada); Representa um caso de uso em que o evento de sistema ocorre (controlador de caso de uso ou sesso).

Low Coupling Usado para avaliao. Atribuir responsabilidades de modo que o acoplamento permanea baixo. High Cohesion Usado para avaliao. Atribuir responsabilidades de modo que a coeso seja alta, de modo a manter a complexidade sob controle. Polymorphism Lida com alteraes de comportamento em hierarquias de classes.
16

Quando comportamentos relacionados variam de acordo com o tipo (classe), atribuir a responsabilidade pelos comportamentos variantes aos tipos relacionados. Pure Fabrication Lida com o equilbrio do baixo aclopamento e da alta coeso. Atribuir um conjunto coeso de responsabilidades a uma classe artificial (que no tem nenhuma relao com os conceitos do domnio do sistema), de modo a aumentar o reuso e manter o baixo aclopamento e a alta coeso. Indirection Utilizados para evitar acoplamento direto entre objetos. Atribuir a responsabilidade de mediador de componentes a um objeto intermedirio, de modo que esses componentes no estejam acoplados diretamente. Protected Variations Utilizado para evitar que alteraes no sistema se propaguem de maneira descontrolada. Identificar partes do sistema que so ou possam vir a ser instveis. Atribuir responsabilidades de modo a criar uma interface estvel que envolva essas partes.

17

15. Referncias
[AUP01] Larman, C. Applying UML and Patterns, 2nd Edition, Prentice Hall, 2001. [C2WIKI03] Portland Pattern Repository AntiPattern, Online: http://c2.com/cgi/wiki?AntiPatterns [GOF95] [JPW02] [POAD03] [POSA96] [PSECT00] Gamma, E. et al Design Patterns: Elements of Reusable Object Oriented Design, Addison-Wesley, 1995. Metsker, S. Java Patterns Workbook, Addison-Wesley, 2002. Yacoub, S., Ammar, H. Pattern Oriented Analisys and Design, Addison-Wesley, 2003 Buschmann, F. et al Pattern-Oriented Software Architecture, Wiley, 1996 Appleton, B. Patterns of Software: Essential Concepts and Terminology, Online: http://www.bradapp.net/docs/patterns-intro.html

18