Análise e Projeto de Software

Padrões de Projeto
Introdução
Profa. Alessandra Alaniz Macedo
Slides adaptados da Introdução do livro
de Padrões de Projeto do Gamma et al
 1. Introdução aos Padrões de
Projeto
2. Descrevendo os Padrões de
Projeto
Tópicos 3. Catálogo de Padrões de
Projeto
4. Como os padrões solucionam
problemas de projeto?
5. Como selecionar um padrão de
projeto?
6. Como usar um padrão de
projeto?
1. Introdução aos Padrões de
Projeto
UML e Padrões de Projeto
● UML indica como expressar um projeto OO
● Padrões de Projeto expressam o resultado do
processo em um exemplo de projeto
● Pessoas sugerem que
○ projetos tem problema, pois as pessoas não estão cientes
do projeto
○ apenas experientes estão
UML e Padrões de Projeto
Padrões
● descrevem a maneira de fazer as coisas
● são coletados e descritos por pessoas que são
experientes em algum tema de projeto
○ assim, outras pessoas podem ler o padrão e ver como
aplicá-lo
Motivação
● Projetar software OO é difícil
○ Projetar software OO reutilizável é mais difícil ainda, pois
deve-se:
■ Identificar objetos pertinentes
■ Fatorá-los em classes no nível correto de granularidade
■ Definir as interfaces das classes
■ Definir hierarquias de herança
■ Estabelecer as associações-chave
Motivação
● Além disso, seu projeto deve
○ ser específico para o problema a resolver
○ ser genérico para atender problemas e requisitos futuros
○ evitar/minimizar reprojeto
● Assim quase impossível um ótimo (reutilizável e flexível)
projeto da 1a vez
● Experiência auxilia no desenvolvimento de bons projetos
O que um projetista deve saber?

● Não resolver cada problema a partir de princípios

elementares (do zero). Reutilizar soluções do
passado
○ Quando encontrar uma boa solução reutilizar
■ Até que essas soluções virem padrões

● Se familiarizar com bons padrões para aplicar a

diferentes problemas de projeto
Um paralelo
● Com autores de roteiros e novelistas
○ Eles raramente projetam suas tramas do zero, pois seguem padrões
■ O herói tragicamente problemático (Macbeth, Hamlet )

■ A novela romântica

● Projetista de softwares OO
○ Eles devem
■ Seguir padrões como "representam estados como objetos”, “adorne objetos de
maneira que possa facilmente acrescentar/remover características”, etc etc

■ Aplicar padrões pois facilitam decisões de projeto

Déja vu
● Bons projetos têm experiência
○ Algumas vezes passamos por problemas que sabemos que
já resolvemos algo parecido antes, embora não sabemos
onde e como
■ Lembrar detalhes do problema anterior e da forma como
resolvemos, nos permitirá reutilizar a experiência em vez de
redescobri-la
■ Contudo normalmente não fazemos um bom trabalho de
registrar
Padrões
“Cada padrão descreve um problema no nosso ambiente e
o cerne da sua solução, de tal forma que se possa usar essa
solução mais de um milhão de vezes, sem nunca fazê-lo da
mesma maneira”

Christopher Alexander
Exemplo - Problema
● Você tem um problema
○ alguns objetos estão executando em um processo no seu
desktop e eles precisam se comunicar com outros objetos
em execução em outro processo
○ Este processo pode estar em seu desktop ou em outro
lugar
Exemplo - Problema
● Você não quer os objetos em seu sistema para não
ter que se preocupar em encontrar outros objetos
na rede ou executar chamadas de procedimento
remoto
● O que você pode fazer?
Exemplo - Solução
● Criar um objeto proxy dentro de seu processo local
para o objeto remoto
● O proxy:
○ tem a mesma interface que o objeto remoto. Seus objetos
locais comunicam-se com o proxy, usando as habituais
mensagens
○ passa a ser responsável por passar qualquer mensagem
para o objeto real, onde quer que resida
Exemplo - Solução
● Os proxies são uma técnica comum usada em redes
e em outros lugares
● As pessoas têm muita experiência em usar proxies
○ Elas sabem como eles podem ser utilizados, quais as
vantagens que eles podem trazer, suas limitações e como
implementar
UML e Padrões de Projeto
● No exemplo do proxy é mais desafiador saber como
diagramar do que aplicar uma solução bem
estabelecida
● O exemplo do proxy, embora útil, não é tão útil
como discutir a experiência envolvendo proxies
UML e Padrões de Projeto
● No início de 1990, algumas pessoas começaram a
capturar essa experiência
● Eles formaram uma comunidade interessada na
escrita de padrões
● Essas pessoas patrocinam conferências e produziram
vários livros
Padrões de Projeto
● Padrões de projeto são descrições de objetos e classes
comunicantes que precisam ser personalizadas para
resolver um problema geral de projeto num contexto
particular
● Um padrão de projeto sistematicamente nomeia, explica
e avalia um aspecto de projeto importante e recorrente
em sistemas orientado a objetos
○ Assim eles tornam mais fácil reutilizar projetos e arquiteturas
bem-sucedidas
Vantagens dos padrões de projeto

● Possibilitam que técnicas testadas e aprovadas tornem-se mais

acessíveis para os desenvolvedores de novos sistemas
● Ajudam a escolher alternativas de projeto que tornam um
sistema reutilizável
● Ajudam a evitar alternativas que comprometam a reutilização
● Podem melhorar a documentação e a manutenção
● Ajudam um projetista a obter mais rapidamente um projeto
adequado
Elementos Essenciais
1. O nome do padrão
2. O problema
3. A solução
4. As consequências
1. O Nome do Padrão
● Referência para descrever um problema de projeto,
suas soluções e consequências em 1 ou 2 palavras
○ Encontrar bons nomes é difícil, mas fundamental para
montar catálogos de projeto, para comunicação,
identificação etc
2. O Problema
● Descreve em que situação aplicar o padrão
● Explica o problema e seu contexto
○ Pode descrever problemas específicos, estruturas de
classes (ou objetos) de um projeto inflexível, ou uma lista
de condições que devem ser satisfeitas para que faça
sentido aplicar o padrão
3. A Solução
● Descreve os elementos que compõem o padrão de
projeto, seus relacionamentos, suas
responsabilidades e colaborações
● Não descreve um projeto concreto ou a
implementação particular
● Fornece descrição abstrata do problema e de como
um arranjo geral de elementos pode resolver
4. As Consequências
● São os resultados e as análises das vantagens e
desvantagens da aplicação do padrão
○ São críticas para decisões de projeto, escolha de
alternativas e compreensão de custo e benefício
○ Envolvem balanceamento de espaço e tempo, aspectos de
linguagem e implementação, impactos em flexibilidade,
extensibilidade ou portabilidade (3 aspectos do reuso)
Padrão de Projeto
● Identifica as classes e instâncias participantes, seus
papéis, colaborações e a distribuição de
responsabilidades
○ a linguagem de programação influencia os projetistas
(usuários de padrões), pois os padrões assumem recursos
do nível da linguagem
2. Descrevendo os Padrões
de Projeto (PP)
Descrevendo um PP
● Cada padrão é dividido em seções de acordo com
um gabarito
○ Gabarito = estrutura uniforme às informações, tornando os
padrões de projeto mais fáceis de aprender, comparar e
usar
Nome e Classificação
● Nome: expressa sua essência de forma sucinta
● Classificação: esquema de agrupamento
Intenção e Objetivo
● Intenção e objetivo: é uma curta declaração que
responde às seguintes questões:
○ O que faz o padrão de projeto?
○ Quais os seus princípios e sua intenção?
○ Que tópico ou problema particular de projeto ele trata?
Também conhecido como
● Apresenta outros nomes do projeto, se houver
Motivação
● Um cenário que ilustra um problema de projeto e
como as estruturas de classes e objetos no padrão
solucionam o problema
Aplicabilidade
● Quais são as situações nas quais o padrão de projeto
pode ser aplicado.
○ Exemplos de maus projetos que ele pode tratar
○ Como você reconhece essas situações
Estrutura e Participantes
● Estrutura: Uma representação gráfica das classes do
padrão
● Participantes: As classes e/ou objetos que
participam do padrão de projeto e suas
responsabilidades
Colaborações e Consequências

● Colaborações: como as classes participantes

colaboram para executar suas responsabilidades
● Consequências: como o padrão suporta a realização
de seus objetivos, quais os custos e benefícios, que
aspecto da estrutura ele permite variar
Implementação e Exemplo de
código
● Implementação: que armadilhas, sugestões ou
técnicas são necessárias conhecer quando da
implementação, existem considerações específicas
da linguagem
● Exemplo de Código formado por fragmentos ou
blocos de código que ilustram como se pode
implementar o padrão em uma linguagem de
programação específica
Usos Conhecidos e Padrões
Relacionados
● Usos conhecidos: exemplos do padrão encontrados
em sistemas reais
● Padrões relacionados: que PPs estão relacionados
com este, quais diferenças e com quais outros
padrões este deveria ser usado??
3. Catálogo de Padrões de
Projeto
Abstract Factory
● Fornece uma interface para criação de famílias de
objetos relacionados ou dependentes sem
especificar suas classes concretas
Adapter
● Converte a interface de uma classe em outra
interface esperada pelos clientes. O Adapter permite
que certas classes trabalhem em conjunto, pois de
outra forma seria impossível por causa de suas
interfaces incompatíveis
Bridge
● Separa uma abstração da sua implementação, de
modo que as duas possam variar
independentemente
Builder
● Separa a construção de um objeto complexo de sua
representação, de modo que o mesmo processo de
construção possa criar diferentes representações
Chain of Responsability
● Evita o acoplamento do remetente de uma
solicitação ao seu destinatário, dando a mais de um
objeto a chance de tratar a solicitação
○ Encadeia objetos receptores e passa a solicitação ao longo
da cadeia até que um objeto a trate
Composite
● Compõe objetos em estrutura de árvore para
representar hierarquia do tipo partes-todo
● Permite que os clientes tratem objetos individuais e
composições de objetos de maneira uniforme
Decorator
● Atribui responsabilidades adicionais a um objeto
dinamicamente
● Fornecem uma alternativa flexível a subclasses para
extensão da funcionalidade
Façade
● 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
Factory Method
● Define uma interface para criar um objeto, mas
deixa as subclasses decidirem qual classe a ser
instanciada
● Permite a uma classe postergar a instanciação ‘as
subclasses
Flyweight
● Uso compartilhamento para suportar grandes
quantidades de objetos, de granularidade fina, de
maneira eficiente
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 nessa linguagem
Iterator
● Fornece uma maneira de acessar sequencialmente
os elementos de uma agregação de objetos sem
expor sua representação subjacente
Mediator
● Define um objeto que encapsula a forma como um
conjunto de objetos interage
● Promove o acoplamento fraco ao evitar que os
objetos se refiram explicitamente uns aos outros,
permitindo que você varie suas interações
independentemente
Memento
● Sem violar o encapsulamento, captura e externaliza
um estado interno de um objeto, de modo que o
mesmo possa posteriormente ser restaurado para
este estado
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
Prototype
● Especifica os tipos de objetos a serem criados
usando uma instância prototípica e cria novos
objetos copiando esse protótipo
Proxy
● Fornece um objeto representante (surrogate), ou um
marcador de outro objeto, para controlar o acesso
ao mesmo
Singleton
● Garante que uma classe tenha somente uma
instância e fornece um ponto global de acesso a ela
State
● Permite que um objeto altere seu comportamento
quando seu estado interno muda
○ O objeto parecerá ter mudado de classe
Strategy
● Define uma família de algoritmos, encapsula cada
um deles e os torna intercambiáveis
● Permite que o algoritmo varie independentemente
dos clientes que o utilizam
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
Visitor
● Representa uma operação a ser executada sobre os
elementos da estrutura de um objeto
● Permite que você defina uma nova operação sem
mudar as classes dos elementos sobre os quais
opera
4. Como os padrões solucionam
problemas de projeto?
Problema: procurando objetos
apropriados
● Objetos empacotam
○ Dados e procedimentos (métodos ou operações)

● (1) as solicitações (request) são a única maneira de

conseguir que um objeto execute uma operação. (2)
as operações são a única maneira de mudar os dados
○ Por causa destas 2 restrições, diz-se que o objeto está
encapsulado. Como decompor objetos?
Problema: procurando objetos
apropriados
● Fatores a serem levados em conta na decomposição
○ Granularidade
○ Dependência
○ Flexibilidade
○ Desempenho
○ Evolução
○ Reutilização
Problema: procurando objetos
apropriados
● Como pensar na decomposição ?
○ Separar verbos e substantivos na descrição do problema na
fase de análise
■ Muitas classes surgem na fase de projeto
○ Pensar sobre colaborações e responsabilidades
○ Modelar o mundo real e na fase de projeto traduzir os
objetos da análise
■ Algumas classes não existem no mundo real
Problema: procurando objetos
apropriados
● Conhecer e analisar as classes dos padrões de
projeto ajuda a identificar abstrações menos óbvias
○ Ex. objetos que representam processos ou algoritmos
■ Strategy: descreve como implementar famílias de algoritmos
intercambiáveis
■ State: representa cada estado de uma entidade como objeto
Problema: determinar a
granularidade
● Facade: representa subsistemas completos como objetos
● Flyweight: descreve como suportar enormes quantidades
de objetos nos níveis de granularidade mais finos
● Abstract Factory e Builder: fornecem objetos cujas
responsabilidades são criar outros objetos
● Visitor e Command: fornecem objetos cujas
responsabilidades são implementar uma solicitação em
outro objeto ou grupo de objetos
Problema: especificar interfaces de
objetos
● Interface = assinatura da operação = nome da operação +
parâmetros + retorno
● Padrões
○ Memento: descreve como encapsular e salvar o estado interno de um
objeto para ser restaurado mais tarde. Objetos Memento tem 2
interfaces
■ Restrita: permite aos clientes manterem e copiarem mementos
■ Privilegiada: somente o objeto original pode armazenar e recuperar
estados no Memento

● Outros: Decorator, Proxy e Visitor

Problema: herança de classe
versus herança de interface
● Classe é como o objeto é implementado
● Tipo de um objeto é a sua interface, e. g., solicitações às quais ele
vai responder
● Em C++, as classes especificam tipo e implementação
● Padrões
○ Chain of Responsability
○ Composite
○ Command
○ Observer, State e Strategy
Problema: como projetar para
mudanças
● A chave para maximização da reutilização está na
antecipação de novos requisitos e mudanças nos
existentes
● Projetar para evoluir
○ Deve considerar
■ Pensar no que o sistema poderá precisar ao longo de sua vida
■ Padrões de projeto ajudam a pensar nisso
■ Cada padrão permite a algum aspecto da estrutura variar
independentemente de outros aspectos
Problema: como projetar para
mudanças
● Causas da reformulação de projetos
○ 1) Criando um projeto pela especificação explícita de uma
classe. Crie objetos indiretamente (apenas interfaces)
■ Abstract Factory, Factory Method e Prototype

○ 2) Criar operações em particular gera dependência de

operações específicas (inflexível)
■ Chain of Responsability e Command
Problema: como projetar para
mudanças
● Causas da reformulação de projetos
○ 3) Software com dependência da plataforma de hardware e
software
■ Abstract Factory e Bridge

○ 4) Clientes que precisam saber como um objeto é

representado, armazenado, localizado ou implementado
■ Abstract Factory, Bridge, Memento e Proxy
Problema: como projetar para
mudanças
● Causas da reformulação de projetos
○ 5) Objetos dependem de algoritmos que podem ser
mudados. Eles devem ser isolados.
■ Abstract Factory, Iterator, Strategy, Template Method e
Visitor
○ 6) Acoplamento forte
■ Abstract Factory, Bridge, Chain of Responsability, Command,
Façade, Mediator e Observer
Problema: como projetar para
mudanças
● Causas da reformulação de projetos
○ 7) Estender objetos pela subclasse
■ Bridge, Chain of Responsability, Composite, Decorator,
Observer e Strategy

○ 8) Incapacidade para alterar classes, pois não tem código

fonte ou efeitos colaterais em outras classes
■ Adapter, Decorator e Visitor
Padrões de Projeto em classes de
software (1/3)
● As 3 grandes classes de software
○ 1) Programas de aplicação
■ Prioridade: reuso interno, facilidade de manutenção e extensão
■ Padrões reduzem dependência de operações específicas,
algorítmica e de representação (aumenta reuso)
■ Padrões limitam a dependência de plataforma e estrutura
(aumenta manutenibilidade)
■ Padrões mostram como estender hierarquias de classes e
explorar composições (aumenta facilidade de extensão)
Padrões de Projeto em classes de
software (2/3)
● As 3 grandes classes de software
○ 2) Toolkits (bibliotecas de classes)
■ Conjunto de classes relacionadas para fornecer
funcionalidades para auxiliar aplicações a realizarem seu
trabalho (evitar recodificação de função comum)
■ Ex. conjunto de classes de coleções para listas, pilhas etc
■ Prioridade: evitar suposições e dependências
Padrões de Projeto em classes de
software (3/3)
● As 3 grandes classes de software
○ 3) Frameworks (arcabouços de classes)
■ Um conjunto de classes cooperantes que constroem um projeto
reutilizável para uma determinada categoria de software
■ Ex de categorias de software: framework para construir
compiladores para diferentes linguagens de programação,
framework para construir aplicações de modelagem financeira,
etc
■ Subclasses especificam a aplicação framework dita a arquitetura
(divisão em classes, de responsabilidade)
Padrões de Projeto em classes de
software (3/3)
● As 3 grandes classes de software
○ 3) Frameworks (arcabouços de classes)
■ Prioridade: flexível para reuso de projeto (classes abstratas) e não de
código, embora inclua subclasses concretas para reuso (extensível se
possível)
■ Framework
■ Captura decisões de projeto do seu domínio
■ Permite a construção de aplicações com estruturas similares (mais fácil
de manter e consistente para usuários)
■ Diminui capacidade criativa no projeto
Diferença de Toolkit e
Framework
● Toolkit implementa-se o corpo principal da aplicação
e chama o código a reutilizar
● Framework reusa o corpo principal e escreve o
código que o corpo chama
○ Difícil pois aposta que sua arquitetura funcionará para
todas as aplicações do domínio
○ Acoplamento deve ser fraco pois mudar framework gera
mudança em aplicações do domínio suportadas por ele
Diferença de Padrão de Projeto e
Framework
● Padrões de projeto ajudam framework a se tornarem
mais reutilizáveis em projeto e código. PP e
framework tem similaridades mas diferem em
○ PP são mais abstratos. Apenas exemplos em PP tem código
○ PP são elementos de arquiteturas menores que
frameworks. Um framework contém vários PPs
○ PP são menos especializados que frameworks
5. Como selecionar um
padrão de projeto?
Como selecionar um PP
● Considere como padrões de projeto solucionam problemas de
projeto (rever slides anteriores de problemas versus PP)
● Examine as seções de Intenções do PP
● Estude como os PPs se interrelacionam (ver Fig.1)
● Estude padrões de finalidades semelhantes
● Examine uma causa de reformulação do projeto (rever slides
anteriores)
● Considere o que deveria ser viável no seu projeto ( ver Fig. 2)
Fig. 1
Fig. 2
PP de Criação PP Estrutural PP Comportamental
Abstract Factory Adapter Chain of Responsability

Builder Bridge Command

Factory Method Composite Interpreter

Prototype Decorator Iterator

Singleton Façada Mediator

Flyweight Memento

Proxy Observer

State

Strategy

Template Method

Visitor

PP por Finalidade
PPs por Finalidade
● Estruturais
○ PPs que geralmente lidam com relacionamentos entre
entidades, tornando mais fácil para essas entidades
trabalharem juntas
● De criação
○ PPs que fornecem mecanismos de instanciação, tornando
mais fácil criar objetos de uma maneira que encaixa na
situação
PPs por Finalidade
● Comportamentais
○ PPs que são usados na comunicação entre entidades
tornando mais fácil e mais flexível para essas entidades se
comunicarem
6. Como usar um padrão de
projeto?
Como usar um PP ?
1) Leia o PP por inteiro, para obter sua visão geral,
especialmente as seções Aplicabilidade e Consequências
2) Volte e estude as seções Estrutura, Participantes e
Colaborações
3) Olhe a seção Exemplo de Código para ver um exemplo
concreto do padrão codificado
4) Escolha nomes para os participantes do padrão que
tenham sentido no contexto da aplicação
Como usar um PP ?
5) Defina as classes, declare suas interfaces, estabeleça
os relacionamentos de herança e defina as variáveis de
instância para dados e referências a objetos
6) Defina nomes específicos da aplicação para as
operações no padrão
7) Implemente as operações para suportar as
responsabilidades presentes no padrão
Quando não usar PP ?
● Quando não precisar da flexibilidade oferecida
○ devido à introdução de níveis adicionais de endereçamento
indireto. Isso pode
■ Complicar um projeto
■ Custar algo em termos de desempenho

● As seções Consequências do PPs são úteis para essa

análise de custo e benefício
REFERÊNCIA
Tutoriais e Documentos
● Design Patterns: Elements of Reusable Object-
Oriented Software, by Gamma Erich, Helm Richard,
Johnson Ralph, Vlissides John and Grady Booch
Tutoriais

Aula de Engenharia de Software do professor Marcelo

Fantinato:
● Engenharia de Software - Aula 12 - Projeto de

software e Padrões de projeto - Canal UNIVESP

○ (a partir dos 17 minutos)
○ https://youtu.be/Zywc5kZyscg
Tutoriais

Vídeo em Português introduzindo design patterns:

● Design Patterns // Dicionário do Programador -

Canal Código Fonte TV

○ (duração de 8 minutos)
○ https://youtu.be/J-lHpiu-Twk
Tutoriais

Playlist sobre Padrões de Projetos com aulas teóricas e

práticas de cada padrão do GoF
● Padrões de Projeto - Design Patterns (GoF) - Canal

Otávio Miranda
○ (45 vídeos)
○ https://youtube.com/playlist?list=PLbIBj8vQhvm0VY5YrM
rafWaQY2EnJ3j8H
Análise e Projeto de Software
Padrões de Projeto
Introdução