Instituto Metodista Bennett

Bruno Pacheco, Olga Khamyanova, Rafael Krejci, Rodrigo Oliveira

Estudo sobre padrões de projeto e

implementação.

Rio de Janeiro
 2009

Bruno Pacheco, Olga Guennadievna Khamyanova, Rafael

Krejci, Rodrigo Oliveira

Estudo sobre padrões de projeto e

implementação.

Monografia apresentada junto ao Curso de

Ciência da Computação do Instituto
Metodista Bennett como requisito parcial à
obtenção do título de Bacharel.

Orientador: Prof. Sávio Figueiredo

Rio de Janeiro
 2009
Errata

Folha Linha Onde se lê Leia se

Bruno Pacheco, Olga Guennadievna Khamyanova, Rafael
Krejci, Rodrigo Oliveira

Estudo sobre padrões de projeto e

implementação.

Monografia apresentada junto ao Curso de

Ciência da Computação do Instituto
Metodista Bennett como requisito parcial à
obtenção do título de Bacharel.

Orientador: Prof. Sávio Figueiredo

COMISSÃO EXAMINADORA

Prof.
Universidade:

Prof.
Universidade:

Prof.
Universidade:
Rio de Janeiro, de 2009
Resumo
Abstract
 Sumário

1. INTRODUÇÃO
2. PADRÕES DE PROJETO – ALGUMAS DEFINIÇÕES
3. PADRÕES DE PROJETO - DESCRIÇÃO
3.1. Criacionais
3.1.1. Fábrica (Factory)
3.1.2. Fábrica Abstrata (Abstract Factory)
3.1.3. Construtor (Builder)
3.1.4. Protótipo (Prototype)
3.1.5. Objeto Unitário (Singleton)
3.2. Estruturais
3.2.1. Adaptador (Adapter)
3.2.2. Composto (Composite)
3.2.3. Decorador (Decorator)
3.2.4. Fachada (Facade)
3.2.5. Ponte (Bridge)
3.2.6. Peso Pena (Flyweight)
3.2.7. Procurador (Proxy)
3.3. Comportamentais
3.3.1. Cadeia de Responsabilidade (Chain of Responsibility)
3.3.2. Comando (Command)
3.3.3. Estado (State)
3.3.4. Estratégia (Strategy)
3.3.5. Gabarito (Template)
3.3.6. Interpretador (Interpreter)
3.3.7. Iterador (Iterator)
3.3.8. Mediador (Mediator)
3.3.9. Observador (Observer)
3.3.10. Recordação (Memento)
3.3.11. Visitante (Visitor)
3.4. Frequência de Uso
3.5. Relacionamento entre os Padrões
4. CONCLUSÃO
5. REFERÊNCIAS BIBLIOGRÁFICAS
1 INTRODUÇÃO

Os desenvolvedores de software têm princípios próprios e soluções

idiomáticas que os guiam na criação de softwares. As dificuldades encontradas são
decorrentes de falta de experiência e da dificuldade de combinação de todos os
elementos que fazem parte do projeto de um sistema complexo. Ao longo dos anos
busca-se cada vez mais a reutilização de código, dentre outros artefatos, com
objetivo de criar sistemas mais robustos, com menor esforço dos desenvolvedores e
maior qualidade do produto final. Neste contexto, surgiu a ideia de catalogar
padrões, princípios a serem seguidos e utilizados na criação de projetos orientados
a objetos.
O objetivo deste trabalho é descrever brevemente os vinte e três padrões
escritos pelo GoF (Gang of Four). Também serão analisados os códigos-fonte de um
sistema pronto com intenção de localizar pontos onde os padrões poderiam
melhorar a qualidade do sistema e , em seguida, implementá-los.
2 PADRÕES DE PROJETO

Profissionais experientes conseguem maior reaproveitamento de código,

isso acontece devido à participação em vários projetos, que demonstram situações
parecidas e soluções padronizadas no nível de classes e de comunicação entre
objetos.
Um padrão de projeto (Design Pattern em inglês) é uma estrutura recorrente
no projeto de software orientado a objetos. Por ser recorrente, vale a pena que seja
documentada e estudada.
Para Craig Larman, “em projeto OO, um padrão é uma descrição
denominada de um problema e solução que pode ser aplicada a novos contextos”.
Para Erich Gamma o objeto primordial dos padrões de projeto é “capturar a
experiência de projeto de uma forma que as pessoas possam usá-la efetivamente”.
Cristopher Alexander apud Erich Gamma afirma: “cada padrão descreve um
problema no nosso ambiente e o cerne da sua solução, de tal forma que você possa
usar essa solução mais de um milhão de vezes, sem nunca fazê-lo da mesma
maneira”.
Eric Braude descreve os padrões de projeto como “combinações de classes
e algoritmos associados que cumpre com propósitos comuns de projeto”. Para ele
“um padrão expressa uma ideia em vez de uma combinação fixa de classes”.

Um padrão de projeto é:
 uma solução padrão para um problema comum de programação;
 uma técnica capaz de tornar o código mais flexível ao fazer com que o código
satisfaça certos critérios;
 um projeto ou uma estrutura de implementação que satisfaz com sucesso um
propósito específico;
 uma maneira mais prática de se descrever certos aspectos da organização de
um programa;
 conexões entre componentes de programas;
 a forma de um diagrama de objeto ou de um modelo de objeto.
 Existem catálogos de vários atores descrevendo padrões de projetos. O
mais abrangente e utilizado foi escrito em 1995 por Erich Gamma, Richar Helm,
Ralph Johnson e John Vlissides, conhecidos como GoF (Gang of Four ou em
português, Gangue dos Quatro), e se chama “Padrões de Projeto, soluções
reutilizáveis de software orientado a objetos”, ou apenas “Design Patterns”.
Seguem as características dos padrões de projeto retirados deste livro:
 tornam mais fácil reutilizar projetos e arquiteturas bem sucedidas;
 técnicas testadas e aprovadas se tornam mais acessível aos
desenvolvedores de novos sistemas;
 ajudam a escolher alternativas de projeto que tornam um sistema reutilizável
e a evitar alternativas que comprometam a reutilização;
 melhoram a documentação e a manutenção de sistemas ao fornecer uma
especificação explícita de interações de classes e objetos e o seu objetivo
subjacente;
 ajudam um projetista a obter mais rapidamente um projeto adequado.
Os 23 padrões catalogados pelo GoF serão chamados daqui em diante
simplesmente como padrões de projeto.
Um padrão de projeto nomeia, abstrai e identifica os aspectos chave de uma
estrutura de projeto comum para torná-la útil para a criação de um projeto orientado
a objetos reutilizável..
Os principais atributos de uma boa descrição de um padrão de projeto são:
 Nome: referência que descreve de forma bastante sucinta o padrão.
 Problema (motivação, intenção e objetivos, aplicabilidade): apresenta o
contexto do padrão e quando ele pode ser usado.
 Solução (estrutura, participantes, exemplo de código): descreve a solução e
os elementos que a compõem.
 Consequências e padrões relacionados: analisa os resultados, vantagens e
desvantagens obtidas com a aplicação do padrão.

Em geral os padrões de projeto podem ser classificados em três diferentes tipos:

Padrões de criação: abstraem o processo de criação de objetos a partir da
instanciação de classes.
Padrões estruturais: tratam da forma como classes e objetos estão organizados para
a formação de estruturas maiores.
Padrões comportamentais: preocupam-se com algoritmos e a atribuição de
responsabilidade entre objetos.

Cada um desses tipos pode ser subclassificado em:

 Padrões de classes: em geral estáticos, definidos em tempo de compilação.
 Padrões de objetos: em geral dinâmicos, definidos em tempo de execução.

Segue abaixo uma tabela retirada do catálogo GoF, que nomeia os padrões e os
classifica tanto ao propósito quanto ao escopo:
Propósito (Purpose)
Criacional Estrutural Comportamental
(Creational) (Structural) (Behavioral)
Fábrica Adaptador (classe) Interpretador
Escopo (Factory Method) (Adapter) (Interpreter)
Classe
Gabarito
(Template Method)
 Fábrica Abstrata Adaptador (objeto) Cadeia de
(Abstract Factory) (Adaptor) Responsabilidade
Construtor Ponte (Chain of
(Builder) (Bridge) responsability)
Protótipo Composto Comando
(Prototype) (Composite) (Command)
Objeto Unitário Decorador Iterador
(Singleton) (Decorator) (Iterator)
Fachada Mediador
(Facade) (Mediator)
Objeto
Peso Pena Recordação
(Flyweight) (Memento)
Procurador Observador
(Proxy) (Observer)
Estado
(State)
Estratégia
(Strategy)
Visitante
(Visitor)
Tabela 1 – Classificação de Padrões de Projeto GoF

3 PADRÕES DE PROJETO - DESCRIÇÃO

3.1 Padrões de Criação

3.1.1 Factory Method define uma interface para criar um objeto, mas deixa
as subclasses decidirem qual classe será instanciada. Permite a uma classe
postergar a instanciação de subclasses.
Uso conhecido: bastante usado em toolkits e frameworks para a instanciação de
objetos.
 Figura 1 – Diagrama de classes – padrão Factory Method

3.1.2 Abstract Factory fornece uma interface para a criação de famílias de

objetos relacionados ou dependentes sem especificar suas classes concretas.
Uso conhecido: transportabilidade entre diferentes bibliotecas de interfaces gráficas
(Gnome e KDE).

Figura 2 – Diagrama de classes – padrão Abstract Factory

 3.1.3 Builder separa a construção (geralmente passo a passo) de um objeto
complexo da sua representação, de modo que o mesmo processo de construção
possa criar diferentes representações.
Uso conhecido: conversão de formatos de texto em editores.

Figura 3 – Diagrama de classes – padrão Builder

3.1.4 Prototype especifica os tipos de objetos a serem criados usando uma

instância prototípica e cria novos objetos copiando este protótipo.
Uso conhecido: depurador Etgdb.

Figura 4 – Diagrama de classes – padrão Prototype

3.1.5 Singleton garante que uma classe tenha somente uma instância e
fornece um ponto global de acesso para ela.
Uso conhecido: programas que só podem ter uma instância sendo executada em um
dado momento.

Figura 5 – Diagrama de classes – padrão Singleton

3.2 Padrões Estruturais

3.2.1 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 impossível por causa de suas interfaces incompatíveis.
Uso conhecido: popularmente conhecido como wrapper, usado para adaptar a
interface de classes.

Figura 6 – Diagrama de classes – padrão Adapter

3.2.2 Composite compõe objetos em estrutura de árvore para representar

hierarquias do tipo partes-todo. Permite que os clientes da estrutura tratem objetos
individuais e composições de objetos de maneira uniforme.
Uso conhecido: para representar hierarquias partes-todo.
 Figura 7 – Diagrama de classes – padrão Composite

3.2.3 Decorator atribui responsabilidades adicionais a um objeto

dinamicamente. Fornece uma alternativa flexível à utilização de subclasses para a
extensão de funcionalidades.
Uso conhecido: para a atribuição de enfeites gráficos e outras funcionalidades
acessórias a widgets.

Figura 8 – Diagrama de classes – padrão Decorator

3.2.4 Facade fornece uma interface unificada para um conjunto de interfaces

em um subsistema. Define uma interface de nível mais alto que torna o subsistema
mais fácil de usar.
Uso conhecido: interface única em sistemas complexos.
 Figura 9 – Diagrama de classes – padrão Facade

3.2.5 Bridge separa uma abstração da sua implementação, de modo que as

duas possam variar independentemente.
Uso conhecido: para evitar o vínculo entre abstração e implementação quando de
mudanças na implementação em tempo de execução.

Figura 10 – Diagrama de classes – padrão Bridge

3.2.6 Flyweight usa compartilhamento para suportar grandes quantidades

de objetos, de granularidade fina, de maneira eficiente.
Uso conhecido: sistemas com grande número de objetos.
 Figura 11 – Diagrama de classes – padrão Flyweight

3.2.7 Proxy fornece um objeto representante ou um marcador de outro

objeto para controlar o acesso ao mesmo.
Uso conhecido: algumas implementações de CORBA.

Figura 12 – Diagrama de classes – padrão Proxy

3.3 Padrões Comportamentais

3.3.1 Chain of Responsibility evita o acoplamento entre o remetente de
uma solicitação e o destinatário da solicitação, dando a mais de um objeto a chance
de tratar a solicitação. Encadeia os objetos receptores e passa a solicitação ao longo
da cadeia até que um objeto a trate.
Uso conhecido: tratamento de eventos de usuário.
 3.3.2 Command encapsula uma solicitação como um objeto, permitindo a
parametrização de clientes com diferentes solicitações, o enfileiramento e o registro
de solicitações e o suporte a operações que possam ser, por exemplo, desfeitas.
Uso conhecido: suporte a “desfazer”.
3.3.3 State permite que um objeto altere seu comportamento quando seu
estado interno muda. O objeto parecerá ter mudado sua classe.
Uso conhecido: em algumas implementações da pilha TCP/IP.
3.3.4 Strategy define uma família de algoritmos, encapsula cada um deles e
os faz intercambiáveis. Permite que o algoritmo varie independentemente dos
clientes que o utilizam.
Uso conhecido: sistemas de otimização.
3.3.5 Template Method define o esqueleto de um algoritmo em uma
operação, postergando a definição 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.
3.3.6 Interpreter dada uma linguagem, define uma representação para sua
gramática juntamente com um interpretador que usa a representação para
interpretar sentenças nesta linguagem.
Uso conhecido: interpretar uma linguagem com uma árvore sintática abstrata, como
em compiladores de linguagens orientadas a objetos.
3.3.7 Iterator fornece uma maneira de acessar sequencialmente os
elementos de um objeto agregado sem expor sua representação subjacente.
Uso conhecido: C++ Standard Template Library.
3.3.8 Mediator define um objeto que encapsula a interação entre um
conjunto de objetos. Promove o acoplamento fraco ao evitar que os objetos se
refiram explicitamente uns aos outros, permitindo a variação das interações
independentemente.
Uso conhecido: arquitetura de aplicações de Smalltalk.
3.3.9 Observer define uma dependência um-para-muitos entre objetos, de
modo que, quando um objeto muda de estado, todos os seus dependentes são
automaticamente notificados e atualizados.
Uso conhecido: propagação de mudanças e atualizações com acoplamento fraco
entre os objetos.
 3.3.10 Memento sem violar a encapsulação, captura e externaliza um
estado interno de um objeto, de modo que o mesmo possa posteriormente ser
restaurado para este estado.
Uso conhecido: armazenar um instantâneo do estado do objeto sem romper sua
encapsulação.
3.3.11 Visitor representa uma operação a ser executada sobre os
elementos de uma estrutura de objetos. Permite a definição de uma nova operação
sem mudar as classes dos elementos sobre os quais opera.
Uso conhecido: para executar uma série de operações sobre objetos que possuem
interfaces diferentes, sem poluir a interface dos mesmos.