ARQUITETURAS E PADRÕES DE SOFTWARE III

Prévia do material em texto

Arquiteturas e 
Padrões de Software 
Responsável pelo Conteúdo:
Prof. Me. Wilson Vendramel 
Revisão Textual:
Prof.ª M.ª Sandra Regina Fonseca Moreira
Padrões de Projeto
Padrões de Projeto
 
 
• Entender a aplicação de padrões de projeto como uma solução reutilizável visando refinar o 
projeto orientado a objetos.
OBJETIVO DE APRENDIZADO 
• Reuso de Software;
• Padrões de Projeto GoF.
UNIDADE Padrões de Projeto
Reuso de Software
Na Unidade anterior, foram listadas as principais atividades a serem realizadas no 
decorrer do projeto orientado a objetos para construir um sistema de software. Assim, 
podemos destacar a utilização de padrões de software, principalmente, nesta unidade, 
os padrões de projeto, do inglês design patterns. Vale lembrar que o projeto orientado a 
objetos consiste em duas atividades principais, sendo o projeto de arquitetura e o projeto 
detalhado. Os padrões de projeto estão situados em um nível de abstração intermediário 
entre o projeto arquitetural e o projeto detalhado.
O que você pensa a respeito do desenvolvimento de um sistema de software novo a partir 
do zero?
Primeiramente, é importante salientar que projetar software orientado a objetos não 
é uma atividade simples, e projetar software orientado a objetos de forma reutilizável 
é uma atividade ainda mais complexa, pois devemos identificar objetos pertinentes, 
realizar a reestruturação (ou refactoring) desses objetos em classes no nível correto de 
granularidade, descrever as interfaces das classes, definir as hierarquias de generaliza-
ção (herança) e estabelecer as devidas relações entre esses conceitos. O projeto (design) 
precisa ser específico para o problema a ser resolvido, mas, ao mesmo tempo, ele pre-
cisa ser genérico o suficiente para contemplar problemas e requisitos futuros, buscando 
também evitar o reprojeto, ou ao menos minimizá-lo. Os desenvolvedores de sistemas de 
software orientados a objetos mais experientes entendem que um projeto reutilizável e 
flexível é difícil, talvez impossível de ser obtido corretamente da primeira vez, pois antes 
mesmo de um projeto estar terminado, os desenvolvedores costumam reutilizá-lo diver-
sas vezes, modificando-o a cada vez que é usado (GAMMA et al., 2000).
É bastante comum dizer que os projetos de software têm determinados problemas 
porque as pessoas envolvidas não possuem conhecimento de outros projetos conduzidos 
por profissionais mais experientes. Os padrões descrevem formas comuns de fazer as 
coisas, sendo coletados por pessoas que identificam temas que se repetem em projetos. 
Essas pessoas analisam cada tema e o descrevem de modo que outras possam entendê-
-lo como um padrão, além de saber como aplicá-lo na prática (FOWLER, 2005).
Os profissionais de desenvolvimento experientes executam bons projetos, ao passo 
que os iniciantes são sobrecarregados pelas diversas opções disponíveis, tendendo a ado-
tar técnicas não orientadas a objetos, inclusive as que já utilizavam antes. Leva um longo 
tempo para os iniciantes aprenderem o que é realmente um bom projeto orientado a ob-
jetos. Os profissionais experientes evidentemente sabem algo que os inexperientes não 
sabem, assim sendo, os melhores arquitetos e programadores sabem que uma coisa que 
eles não devem fazer é resolver cada problema a partir de princípios elementares ou do 
zero. Ao invés disso, eles reutilizam soluções que já funcionaram no passado. Quando 
uma boa solução é encontrada, eles a utilizam de forma repetitiva. Consequentemente, 
são identificados padrões de classes e de comunicação entre objetos que surgem com 
frequência no desenvolvimento de sistemas orientados a objetos. Esses padrões resolvem 
8
9
problemas de projeto (design) e tornam os projetos orientados a objetos mais flexíveis e 
reutilizáveis. O s padrões ajudam os desenvolvedores a reutilizar projetos bem-sucedidos 
na realização de novos projetos. Um arquiteto ou programador familiarizado com tais 
padrões pode aplicá-los de maneira imediata em diferentes problemas de projeto, sem a 
necessidade de descobri-los novamente (GAMMA et al., 2000).
Por que se usa o termo padrão?
A história dos padrões de software não tem início com um cientista da computação, 
mas com o arquiteto (não de software) Christopher Alexander, que identificou um con-
junto de problemas recorrentes toda vez que um edifício era projetado (PRESSMAN; 
MAXIM, 2016).
Segundo Christopher Alexander, “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” (AIS, 1977 apud GAMMA et 
al., 2000, p. 19). Embora ele estivesse falando sobre padrões em construções e cidades, 
o que ele diz é verdadeiro no que diz respeito aos padrões de projeto orientados a objeto, 
sendo que no contexto de desenvolvimento de software, as soluções são expressas em 
termos de objetos e interfaces ao invés de paredes e portas, ainda assim, na essência de 
ambos os tipos de padrões, consta a solução para um problema em um contexto particular. 
O s melhores projetos usam muitos padrões que se encaixam e se entrelaçam para construir 
um todo maior (GAMMA et al., 2000). Nesse caso, o todo pode ser visto como o sistema 
de software a ser construído com a reutilização de diversos padrões existentes.
U m padrão é uma solução para um problema, portanto, ele precisa identificar o problema 
de forma clara, explicar como ele soluciona tal problema e em quais circunstâncias ele funciona 
ou não. Um padrão é muito mais do que um modelo. Os padrões oferecem uma série de 
soluções, mostram o que faz um bom modelo e como você deve proceder para construir esse 
modelo. Em suma, o s padrões ensinam com base em exemplos (FOWLER, 2005).
Um artigo sobre o impacto dos padrões de projeto em 20 anos. Disponível
em: https://bit.ly/3snzRxw
Vimos que, ao estudar padrões, estamos lidando com um nível de reuso de software. 
A reutilização de softwares existentes é uma abordagem de desenvolvimento de software, 
propiciando o desenvolvimento de novos sistemas de software de forma mais rápida, 
com menor risco de desenvolvimento e custos mais baixos. Como o software reusado já 
foi testado em outras aplicações, tudo indica que essa abordagem de desenvolvimento é 
mais confiável que a construção de um novo software. O reuso de software é possível 
em vários níveis distintos, assim como mostra a Figura 1. Esses níveis são:
• N ível de abstração: você não reutiliza o software ®, mas usa o conhecimento 
das abstrações de sucesso no projeto de seu software. O s padrões de projeto e de 
arquitetura são formas de representar o conhecimento abstrato para reutilização; 
• Nível de objeto: você reutiliza objetos diretamente de uma biblioteca, ao invés de 
escrever um código. P ara implementar esse tipo de reuso, você precisa encontrar 
bibliotecas adequadas e descobrir se os objetos e métodos oferecem a funcionalidade 
9
UNIDADE Padrões de Projeto
que está buscando. Se você precisa processar mensagens de correio em um programa 
Java, por exemplo, você pode usar objetos e métodos de uma biblioteca JavaMail;
• Nível de componente: componentes são coleções de objetos e classes de objetos 
que trabalham em conjunto para fornecer funções e serviços relacionados. Em muitas 
situações, você precisa adaptar e ampliar o componente adicionando um código 
próprio. Um exemplo de reutilização em nível de componente é aquele no qual você 
constrói sua interface de usuário com o apoio de um framework;
• Nível de sistema: você reutiliza os sistemas de aplicação de forma completa, nor-
malmente envolvendo algum tipo de configuração desses sistemas, que pode ser 
feita por meio da adição e modificação do código ou pelo uso de interface de confi-
guração do próprio sistema. Muitos sistemas comerciais são construídos dessa ma-
neira, em que sistemas genéricos denominados COTS (Commercial Off-The-Shelf), 
também chamados de sistemas ou componentes de prateleira, sãoadaptados e 
reusados. Em alguns casos, essa abordagem pode envolver o reuso e a integração 
de diversos sistemas para construir um novo (SOMMERVILLE, 2019).
Reúso de software Frameworksde componente
Padrões de arquitetura 
e projeto
Sistema de aplicação
(COTS)
Componente
Sistema
Abstração
Bibliotecas de linguagem
de programação
Objeto
Figura 1 – Reuso de Software
Fonte: Adaptado de SOMMERVILLE, 2019, p. 192
A engenharia de software reconhece que para conseguir um software melhor, de for-
ma mais rápida, e com custos menores, é necessário um processo de desenvolvimento 
de software baseado no reuso sistemático de softwares existentes. Em um processo de 
desenvolvimento orientado ao reuso, você busca elementos reutilizáveis e, em seguida, 
adequa seu projeto e requisitos visando fazer um melhor uso deles. As abordagens orien-
tadas ao reuso precisam de um catálogo de componentes de software reutilizáveis e de um 
framework de integração para a composição desses componentes, enfatizando três tipos 
de componentes de software reutilizados com frequência:
• Sistemas de aplicação stand-alone configurados para utilização em um ambiente 
específico. Esses sistemas são de uso geral e têm diversas características, porém, 
precisam ser adaptados para uso em uma determinada aplicação;
• Web services desenvolvidos conforme os padrões de serviço, estando disponíveis 
para uso remoto na internet (SOMMERVILLE, 2019);
• Coleções de objetos desenvolvidos como um componente ou como um pacote que 
deve ser integrado a um framework de componentes, como, por exemplo, o Java 
Spring Framework (WHEELER; WHITE, 2013 apud SOMMERVILLE, 2019, p. 37).
10
11
Spring é um framework open source para a plataforma Java. Para maiores informações 
sobre esse framework, você pode consultar do link: https://bit.ly/39y0UxE
Como padrões de projeto e frameworks são formas de reuso e possuem seme-
lhanças, é comum se confundir e perguntar: quais as diferenças entre eles?
Esses conceitos se diferenciam basicamente em três aspectos:
• O s padrões de projeto são mais abstratos que os frameworks. Enquanto os frameworks
podem ser materializados em código, somente exemplos de padrões podem ser mate-
rializados em código. Um ponto forte dos frameworks é que eles podem ser escritos 
em uma linguagem de programação, sendo não apenas estudados, mas executados e 
reutilizados diretamente. Em contrapartida, os padrões de projeto precisam ser imple-
mentados cada vez que são usados, além de explicar as intenções, custos e benefícios 
(trade-offs) e consequências de um projeto; 
• O s padrões de projeto são elementos de arquitetura menores que os frameworks. Um 
framework típico tem vários padrões de projeto, mas a recíproca nunca é verdadeira;
• O s padrões de projeto são menos especializados que os frameworks. Os frameworks 
sempre são vinculados a um domínio particular de aplicação. Um framework para 
um editor gráfico poderia ser usado na simulação de uma fábrica, porém, ele não 
seria confundido com um framework para simulação. E m contraposição, os padrões 
de projeto podem ser usados em quase qualquer tipo de aplicação. E mbora haja 
padrões de projeto mais especializados, como padrões para sistemas distribuídos ou 
programação concorrente, estes também não ditam a arquitetura de uma aplicação 
da forma como um framework o faz (GAMMA et al., 2000).
Importante!
“F ramework é uma ‘miniarquitetura’ reutilizá vel que serve como base para e a partir da 
qual outros padrões de projeto podem ser aplicados.” (PRESSMAN; MAXIM, 2016, p. 351).
Segundo Martin Fowler, “O s padrões são semiprontos – isso significa que sempre temos 
de finalizá-los e adaptá-los ao nosso ambiente” (PRESSMAN; MAXIM, 2016, p. 352).
Ainda segundo Gamma et al. (2000), os frameworks estão cada vez mais comuns e 
importantes, pois são a maneira pela qual os sistemas orientados a objetos conseguem a 
maior reutilização. Os sistemas de software costumam ser constituídos por camadas de 
frameworks que cooperam uns com os outros. É fato que a maior parte do projeto e do 
código da aplicação de software tende a vir dos frameworks que ele utiliza, e se assim 
não for, será no mínimo influenciado por eles.
Quanto ao processo de desenvolvimento de software baseado em reuso? Há algum 
modelo de processo?
A Figura 2 apresenta um modelo de processo articulado em torno da integração e 
da configuração para o desenvolvimento de software orientado ao reuso, apresentando 
cinco atividades principais:
11
UNIDADE Padrões de Projeto
• Especificação dos requisitos: os requisitos iniciais são apresentados sem tantos deta-
lhes, porém, essa especificação deve incluir descrições resumidas dos requisitos mais 
importantes e das propriedades desejadas para o software;
• Descoberta e avaliação do software: a partir da descrição dos requisitos do software, 
é realizada uma busca por componentes e sistemas que fornecem a funcionalidade 
exigida. Os componentes e sistemas candidatos são avaliados para verificar se atendem 
aos requisitos essenciais e se são adequados ao sistema;
• Refinamento dos requisitos: os requisitos são estabelecidos a partir das informações 
dos componentes reutilizáveis e das aplicações descobertas. Os requisitos são adapta-
dos para refletir os componentes disponíveis e a especificação do sistema de software 
é redefinida. Quando as modificações forem inviáveis, a atividade da análise de com-
ponentes pode ser realizada novamente, objetivando buscar soluções alternativas;
• Configuração da aplicação: havendo uma aplicação de prateleira disponível que 
satisfaça aos requisitos, ela pode ser configurada e utilizada para criar o novo produto 
de software;
• Adaptação e integração dos componentes: não havendo uma aplicação de pra-
teleira disponível, componentes reutilizáveis podem ser modificados ou novos com-
ponentes podem ser desenvolvidos com o intuito de fazer a integração destes ao 
sistema de software (SOMMERVILLE, 2019).
Especi�cação 
dos requisitos
Re�namento 
dos requisitos
Con�guração 
de aplicação
Aplicação
disponível
Componentes 
disponíveis
Adaptação dos
componentes
Integração
do sistema
Desenvolvimento
dos componentes
Descoberta do
software
Avaliação do
software
Figura 2 – Engenharia de software orientada para o reuso 
Fonte: Adaptado de SOMMERVILLE, 2019, p. 38
A Figura 3 exibe um panorama do reuso de software apresentando diversas alternativas 
para implementar a reutilização de software. Observe que há várias técnicas para apoiar o 
reuso em diferentes níveis, desde as funções mais simples até as aplicações inteiras.
Frameworks
de aplicação
Sistemas de 
sistemas
Padrões de 
projeto
Padrões de 
arquitetura
Integração de sistema
de aplicação
Empacotamento de
sistemas legados
Sistemas orientados
a serviços
Biblioteca de programas Sistemas ERP
Linhas de produtos
de software
Sistemas de aplicação
con�guráveis 
Engenharia dirigida
por modelos
Geradores de programas
Engenharia de software
baseada componentes
Engenharia de software
orientada a aspectos
Figura 3 – Panorama do reuso de software
Fonte: Adaptado de SOMMERVILLE, 2019, p.412
12
13
O uso de padrões tem se tornado, no decorrer dos anos, uma prática comum e apro-
priada para atingir o reuso e o desenvolvimento de produtos de software de qualidade. 
Os padrões de software são aplicáveis em diversos cenários ao longo do processo de 
software (BEZERRA, 2015). São diversos tipos de padrões empregados no desenvolvi-
mento, tais como padrões de análise, padrões de projeto, padrões de arquitetura, padrões 
de implementação (idioms). A lista de padrões é bastante vasta, sendo alguns exemplos:
• O padrão arquitetural M odel-View-Controller (MVC), cujo propósito é organizar 
aplicações que devem prover interfaces com o usuário, na maior parte das vezes 
gráficas (BUSCHMANN, 1996 apud BEZERRA, 2015, p. 189);
• Os padrões de projeto do catálogo Java Enterprise Edition (JEE), como F ront 
Controller e View Helper, que são utilizados na implementação do padrãoMVC 
em aplicações Web, assim como o padrão Data Transfer Object (DTO), que é 
utilizado para transferência de informações entre nós de processamento (ALUR et 
al., 2003 apud BEZERRA, 2015, p. 189);
• O padrão de projeto DAO (Data Access Object), cuja finalidade é desacoplar a 
aplicação do mecanismo de armazenamento persistente utilizado. Esse é outro 
padrão do catálogo JEE (ALUR et al., 2003 apud BEZERRA, 2015, p.189);
• Os padrões de projeto GoF, reunidos em um catálogo de 23 padrões de projeto 
clássicos do paradigma da orientação a objetos (GAMMA et al., 2000 apud 
BEZERRA, 2015, p. 189);
• Os p adrões táticos do Domain-Driven Design (DDD) (EVANS, 2003 apud BEZERRA, 
2005, p. 189). DDD é uma filosofia passível de aplicação ao processo de concepção 
arquitetural de um software, composta por princípios que se alinham com os valores e 
princípios do Manifesto Ágil (PRIKLADNICKI; WILLI; MILANI, 2014).
Um catálogo de padrões JEE apresentando melhores práticas e estratégias de design. 
Disponível em: https://bit.ly/3bIcid2
Para maiores informações sobre Domain-Driven Design (DDD), você também pode explorar 
o capítulo 10 do livro “Métodos ágeis para desenvolvimento de software”, organizado por 
Rafael Prikladnicki, Renato Willi e Fabiano Milani. Disponível na Biblioteca Virtual da Universidade.
E quanto aos padrões de projeto que tanto nos interessam? É o que vamos apresentar 
a partir da próxima seção desta unidade. Já os padrões arquiteturais, esses serão abor-
dados a partir da próxima unidade.
Padrões de Projeto GoF
A s ideias de Christopher Alexander, mencionadas nesta unidade, foram traduzidas 
inicialmente para o mundo de desenvolvimento de software em livros. Atualmente, há 
13
UNIDADE Padrões de Projeto
dezenas de repositórios de padrões, sendo que projetos baseados em padrões podem ser 
aplicados em diversos domínios de negócio (PRESSMAN; MAXIM, 2016). Na década 
de 90, alguns profissionais começaram a catalogar experiências adquiridas em proje-
tos de desenvolvimento de software, formando assim uma comunidade interessada em 
escrever padrões, com destaque para o livro sobre padrões de projeto da Gangue dos 
Quatro, do inglês Gang of Four (GoF), que cataloga e descreve 23 padrões de projeto 
detalhadamente (FOWLER, 2005).
Por que usar padrões de projeto é uma prática importante no desenvolvimento de 
sistemas de software?
Os padrões de projeto facilitam a reutilização de projetos e arquiteturas bem sucedidas, 
já que expressar técnicas testadas e aprovadas as torna mais acessíveis para os desen-
volvedores de novos produtos de software. Os padrões de projeto ajudam na escolha de 
alternativas de projeto que tornam um sistema reutilizável e também a evitar caminhos 
que comprometam o reuso. Além disso, os padrões de projeto ajudam a melhorar a docu-
mentação e a manutenção de sistemas de software ao oferecer uma especificação explícita 
de interações de classes e objetos e o seu objetivo que está subentendido. Em síntese, os 
padrões de projeto auxiliam arquitetos e programadores a obterem um projeto adequado 
de forma mais rápida (GAMMA et al.,2000). Como os padrões de projeto são represen-
tações abstratas intermediárias entre o projeto de arquitetura e o projeto detalhado, eles 
costumam ser usados para refinar os componentes de uma arquitetura, e também como 
marco inicial das atividades relacionadas ao projeto detalhado.
“Um padrão de projeto corresponde a um esboço de uma solução reusável para um 
problema comumente encontrado em um contexto particular. Estudar padrões é uma 
maneira eficaz de aprender com a experiência de outros” (BEZERRA, 2015, p. 294).
Assim, quais elementos compõem um padrão de projeto?
De modo geral, Gamma et al. (2000) destacam quatro elementos essenciais de 
um padrão:
• Nome do padrão: uma referência usada para descrever um problema de projeto, 
suas soluções e consequências, em uma ou duas palavras. Nomear um padrão au-
menta de modo imediato o vocabulário de projeto, permitindo assim projetar em um 
nível mais alto de abstração. Um vocabulário para padrões permite dialogar a respeito 
com colegas do time de desenvolvimento, na documentação e até com nós mesmos;
• Problema: descreve em qual cenário o padrão deve ser aplicado, pois explica o 
problema e seu contexto, podendo descrever problemas de projeto específicos, por 
exemplo, a representação de algoritmos como objetos; outro exemplo é a descrição 
de estruturas de classe ou objeto de um projeto sem flexibilidade. Em alguns casos, 
o problema inclui uma relação de condições que devem ser atendidas para haver 
sentido ao aplicar o padrão;
• Solução: descreve os elementos que fazem parte do padrão de projeto, seus rela-
cionamentos, suas responsabilidades e colaborações. A solução não descreve um 
projeto concreto ou uma implementação específica porque um padrão é como 
um esboço que pode ser aplicado em muitos cenários distintos. Ao invés disso, 
o padrão fornece uma descrição abstrata de um problema de projeto e como um 
conjunto geral de elementos (classes e objetos) o resolve;
14
15
• Consequências: refletem os resultados e análises dos ganhos e perdas (trade-offs) 
da aplicação do padrão. Embora as consequências sejam raramente apresentadas 
nas decisões de projeto, elas são importantes para avaliar alternativas de projetos 
e para o entendimento das vantagens e desvantagens da aplicação do padrão. As 
consequências para o software geralmente envolvem o equilíbrio entre espaço e 
tempo, podendo abordar também questões relacionadas com linguagens e imple-
mentação. Dado que a reutilização é normalmente um fator a ser considerado no 
projeto orientado a objetos, as consequências de um padrão devem incluir uma 
análise de impacto sobre a flexibilidade, extensibilidade ou portabilidade de um 
software, portanto, correlacionar essas consequências de forma clara ajuda a com-
preendê-las e avaliá-las.
Os padrões de projeto têm variações em sua granularidade e no seu nível de abstração. 
Por conta de haver muitos padrões, estes são classificados com o objetivo de organizá-los 
melhor, permitindo assim nos referir a uma família de padrões relacionados. Essa classifica-
ção auxilia no aprendizado de padrões de forma mais rápida, como também ajuda a direcio-
nar esforços na descoberta de novos padrões. 
Os padrões de projeto foram classificados a partir de dois critérios, sendo que o pri-
meiro critério corresponde à finalidade do padrão, ou seja, o que o padrão faz. Nesse 
caso, um padrão pode ser de categoria criacional, estrutural ou comportamental. Os pa-
drões criacionais enfatizam o processo de construção dos objetos; os padrões estruturais 
lidam com a estrutura das classes ou objetos; já os padrões comportamentais descrevem 
as maneiras pelas quais as classes ou objetos interagem e distribuem responsabilidades. 
O segundo critério é correspondente ao escopo do padrão, definindo se o padrão é 
aplicável no escopo de classes ou de objetos.
Os padrões para classes buscam relacionamentos entre classes e suas subclasses, de-
finidos por meio de herança, sendo dessa forma, estáticos, pois trabalham em tempo de 
compilação, já os padrões para objetos visam os relacionamentos entre objetos que po-
dem sofrer mudanças em tempo de execução, sendo assim, mais dinâmicos (GAMMA 
et al., 2000).
Ainda segundo Gamma et al. (2000), os padrões de projeto criacionais para clas-
ses deixam alguma parte da construção de objetos a cargo das subclasses, enquanto 
os padrões criacionais para objetos deixam a criação para outro objeto. Os padrões 
estruturais para classes usam a herança para montar classes, e os padrões estruturais de 
objetos descrevem formas de compor objetos. Os padrões comportamentais para classe 
utilizam herança para descrever algoritmos e fluxos de controle, e os padrões compor-
tamentais para objetos definem como um grupo de objetos colabora para executar uma 
tarefa que um objeto não pode executar sozinho.
A tabela 1 apresenta o espaço dos padrões de projeto GoF, organizadosde acordo 
com os dois critérios de classificação apresentados. Ao todo, são 23 padrões de projeto, 
sendo que pelo critério de finalidade, são 5 padrões criacionais, 7 estruturais e 11 com-
portamentais. Pelo outro critério, de classificação, são 4 padrões de escopo de classes e 
19 padrões de escopo de objetos.
15
UNIDADE Padrões de Projeto
Tabela 1 – O espaço dos padrões de projeto
Finalidade
Criacional Estrutural Comportamental
Escopo
Classe Factory Method Adapter
Interpreter
Template Method
Objeto
Abstract Factory
Builder
Prototype
Singleton
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
Fonte: Adaptado de GAMMA et al., 2000, p. 26
Outra forma de organizar os padrões de projeto GoF é com base nas relações exis-
tentes entre eles (padrões relacionados). A Figura 4 exibe essa organização.
Figura 4 – Relacionamentos entre padrões de projeto
Fonte: GAMMA et al., 2000, p. 27
16
17
Importante!
Existem, claramente, muitas maneiras de organizar os padrões de projeto. Ter múlti-
plas maneiras de pensar a respeito deles aprofundará sua percepção sobre o que fazem, 
como se comparam e quando aplicá-los (GAMMA et al., 2000, p. 26).
E quanto à intenção de cada padrão de projeto GoF?
Esta unidade apresenta a intenção de cada padrão de projeto GoF com base no livro 
de Gamma et al. (2000). Vale ressaltar que os padrões são tratados em um certo nível 
de abstração, onde os projetos não se referem a nenhum domínio de negócio específico 
para uma aplicação completa, ou mesmo para um subsistema , isto é, “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” (GAMMA et al., 2000, 
p. 20). Os 23 padrões são listados aqui em ordem alfabética. Além da apresentação da 
intenção, a finalidade e o escopo de cada padrão elencados na Tabela 1 são relembrados. 
Dessa forma, temos:
• Abstract Factory: padrão criacional e de escopo de objeto cuja intenção é prover 
uma interface para fabricar famílias de objetos vinculados, ou que tenham depen-
dência sem descrever suas classes concretas;
• Adapter: padrão estrutural e de escopo de classe cuja intenção é transformar a 
interface de uma classe em outra interface a ser usada pelos clientes (objetos). Esse 
padrão possibilita que classes com interfaces sem compatibilidade atuem conjunta-
mente, sendo que, de outra maneira, seria impossível;
• Bridge: padrão estrutural e de escopo de objeto cuja intenção é separar uma abstra-
ção de sua implementação, permitindo que ambas variem de forma independente;
• Builder: padrão criacional e de escopo de objeto cuja intenção é separar a criação 
de um objeto complexo da sua representação, desse modo, permite a criação de 
representações distintas a partir do mesmo processo de criação;
• Chain of Responsibility: padrão comportamental e de escopo de objeto cuja in-
tenção é impedir o acoplamento entre o objeto remetente de uma solicitação e seu 
objeto receptor, propiciando condições para que mais de um objeto trate essa soli-
citação. Esse padrão organiza os objetos receptores de forma encadeada e passa a 
solicitação no decurso dessa cadeia até que um objeto assuma essa responsabilidade 
de tratamento de solicitação;
• Command: padrão comportamental e de escopo de objeto cuja intenção é encap-
sular uma solicitação como um objeto, permitindo assim configurar clientes (objetos) 
com solicitações distintas, enfileirar ou registrar solicitações. Além disso, esse pa-
drão suporta operações que possam ser desfeitas;
• Composite: padrão estrutural e de escopo de objeto cuja intenção é realizar a com-
posição de objetos em estruturas de árvore de modo que estas representam hierar-
quias partes-todo. Esse padrão possibilita aos clientes (objetos) tratarem de forma 
análoga objetos individuais e composições de objetos;
17
UNIDADE Padrões de Projeto
• Decorator: padrão estrutural e de escopo de objeto cuja intenção é adicionar res-
ponsabilidade a um objeto de forma dinâmica. Esse padrão oferece uma alternativa 
flexível na utilização de subclasses, visando estender sua funcionalidade;
• Façade: padrão estrutural e de escopo de objeto cuja intenção é prover uma inter-
face única para um conjunto de interfaces em um subsistema. Esse padrão estabe-
lece uma interface de nível mais alto, facilitando assim o uso desse subsistema;
• Factory Method: padrão criacional e de escopo de classe cuja intenção é estabele-
cer uma interface para criação de um objeto, permitindo porém, que as subclasses 
decidam qual classe instanciar. Esse padrão possibilita passar a instanciação para 
as subclasses;
• Flyweight: padrão estrutural e de escopo de objeto cuja intenção é usar comparti-
lhamento para suportar de maneira eficiente muitos objetos de granularidade fina;
• Interpreter: padrão comportamental e de escopo de classe cuja intenção é definir 
uma representação para a sua gramática junto com um interpretador que utiliza a 
representação para interpretar sentenças de uma determinada linguagem;
• Iterator: padrão comportamental e de escopo de objeto cuja intenção é propiciar 
uma forma de acessar, de modo sequencial, os elementos de um objeto agregado 
sem exibir sua representação que está implícita;
• Mediator: padrão comportamental e de escopo de objeto cuja intenção é estabele-
cer um objeto que encapsula a forma de interação de um grupo de objetos. Esse pa-
drão propicia o acoplamento fraco ao não permitir que os objetos façam referência 
uns aos outros de modo explícito, além de possibilitar variações de suas interações 
de maneira independente;
• Memento: padrão comportamental e de escopo de objeto cuja intenção é capturar 
e revelar um estado interno de um objeto sem violar o encapsulamento, de modo 
que o objeto possa ser restaurado para esse estado posteriormente;
• Observer: padrão comportamental e de escopo de objeto cuja intenção é estabe-
lecer uma dependência um-para-muitos entre objetos, de forma que um objeto, ao 
mudar de estado, notifique e atualize seus dependentes de modo automático;
• Prototype: padrão criacional e de escopo de objeto cuja intenção é definir os tipos 
de objetos a serem construídos a partir de uma instância vista como protótipo e 
construir novos objetos com base na cópia desse protótipo;
• Proxy: padrão estrutural e de escopo de objeto cuja intenção é oferecer um substituto 
ou marcador da localização de outro objeto visando controlar o acesso a esse objeto;
• Singleton: padrão criacional e de escopo de objeto cuja intenção é permitir que 
uma classe possua apenas uma instância, e que sirva como um ponto global de 
acesso ao objeto;
• State: padrão comportamental e de escopo de objeto cuja intenção é propiciar a 
um objeto mudar seu comportamento quando o seu estado interno é modificado. 
Nesse caso, esse objeto vai parecer ter mudado sua classe;
• Strategy: padrão comportamental e de escopo de objeto cuja intenção é estabe-
lecer uma família de algoritmos, encapsulando cada uma delas, tornando-as inter-
cambiáveis. Esse padrão possibilita ao algoritmo variar de modo independente de 
seus clientes (objetos);
18
19
• Template Method: padrão comportamental e de escopo de classe cuja intenção é 
definir a estrutura de um algoritmo em uma operação, transferindo alguns passos para 
suas subclasses. Esse padrão propicia às subclasses redefinirem determinados passos 
de um algoritmo sem modificar a estrutura desse algoritmo;
• Visitor: padrão comportamental e de escopo de objeto cuja intenção é retratar uma 
operação a ser executada nos elementos de uma estrutura de objetos. Esse padrão 
possibilita a definição de uma nova operação sem alterar as classes desses elementos 
sobre as quais ele atua.
Para maiores informações sobre os padrões GoF listados nesta unidade, você pode explorar 
o livro “Padrões de projeto: soluções reutilizáveis de software orientadoa objetos”, de 
Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides, disponível na Biblioteca Virtual 
da Universidade.
Diante de tantos padrões de projeto surge a pergunta: por qual padrão eu devo co-
meçar a estudar?
Vamos lá. Segundo Gamma et al. (2000), se você ainda não tem experiência com 
design e implementação de sistemas de software orientado a objetos, é interessante 
começar com os padrões mais simples e mais comuns, como: a) Abstract Factory; b) 
Adapter; c) Composite; d) Decorator; e) Factory Method; f) Observer; g) Strategy e; h) 
Template Method. Além disso, é difícil encontrar um software orientado a objetos que 
não utilize ao menos dois desses padrões; já sistemas de grande porte utilizam quase 
todos eles. Esse subgrupo de padrões tanto ajuda a compreender os padrões de projeto 
em si, como também a ter uma compreensão do bom projeto orientado a objetos.
Além dos elementos essenciais de um padrão (nome, problema, solução e consequên-
cias), os materiais costumam apresentar a estrutura do padrão por meio de representa-
ção gráfica, inclusive usando notações UML. Outros materiais trazem a implementação 
dos padrões em uma linguagem de programação específica. Essas informações adicio-
nais podem tornar os padrões mais fáceis de serem aprendidos, comparados e usados.
Para detalhes sobre aplicação de padrões de projeto GoF, você pode explorar os capítulos 26 
e 36 do livro “Utilizando UML e padrões: uma introdução à análise e ao projeto orientados 
a objetos e ao desenvolvimento iterativo”, de Craig Larman, disponível na Biblioteca Virtual 
da Universidade.
Você pode consultar um catálogo de padrões de projeto GoF contendo propósito, problema, 
solução, estrutura, pseudocódigo, aplicabilidade, como implementar, prós e contras, rela-
ções com outros padrões e exemplos de código. Disponível em: https://bit.ly/35IPsOF
19
UNIDADE Padrões de Projeto
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Sites
Spring Framework
https://bit.ly/39y0UxE
Core J2EE Patterns
https://bit.ly/3bIcid2
O Catálogo dos Padrões de Projeto
https://bit.ly/35IPsOF
 Leitura
O Impacto dos Padrões de Projeto em Vinte Anos
https://bit.ly/3snzRxw
20
21
Referências
BEZERRA, E. Princípios de Análise e Projeto de Sistemas com UML. 3.ed. São 
Paulo: Elsevier, 2015.
FOWLER. M. UML Essencial: um breve guia para a linguagem-padrão de modelagem 
de objetos. 3.ed. Porto Alegre: Bookman, 2005.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de projeto: soluções 
reutilizáveis de software orientado a objetos. 1.ed. Porto Alegre: Bookman, 2000.
LARMAN, C. Utilizando UML e padrões: uma introdução à análise e ao projeto orien-
tados a objetos e ao desenvolvimento iterativo. 3.ed. Porto Alegre: Bookman, 2007.
PRESSMAN, R. S.; MAXIM. B. R. Engenharia de software. 8.ed. Porto Alegre: 
AMGH, 2016.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de 
software. Porto Alegre: Bookman, 2014. 
SOMMERVILLE, I. Engenharia de software. 10.ed. São Paulo: Pearson, 2019. 
21