Padrões de Projeto em Software

Prévia do material em texto

6ºAula
Padrões de projeto
Objetivos de aprendizagem
Ao término desta aula, vocês serão capazes de: 
•	 saber o que são padrões de projeto;
•	 entender como aplicar na prática esses padrões.
Olá, pessoal, como vai? 
Finalizando os nossos estudos de Projeto de Software, 
vamos a um item muito importante, os Padrões de Projeto. 
Muitas vezes, em sua jornada profissional, você se depara com 
muitas soluções para problemas bem definidos. E essas soluções 
podem ser reproduzidas para resolver outros problemas 
similares. É esse o conceito chave de padrões de projeto.
Nesta aula, veremos alguns padrões GoF, outras categorias 
de padrões que são aplicadas e como aplicar os padrões de 
projeto na vida real.
Não se esqueçam de fazer as atividades e visitar a nossa 
área acadêmica para resolver as suas dúvidas. E lembre-se de 
que esse conteúdo é um conteúdo bem vasto. Portanto, não 
deixem de pesquisar sobre o assunto.
Vamos lá?
Bons estudos!
Engenharia de Requisitos 44
Seções de estudo
1 - Padrões de Projeto
2 - Padrões de Projeto Orientado a Objetos
3 - Outros tipos de padrões de projeto
4 - Aplicando os padrões de projeto
1 - Padrões de Projeto
Você deve ter visto nas matérias anteriores que a 
reutilização é importante para agilizar o desenvolvimento de 
software. Em todo o contexto de desenvolvimento de 
software, milhares de software foram desenvolvidos, para 
resolver diversos problemas. Durante o processo de 
desenvolvimento, os programadores encontraram diversas 
abordagens de modelagem de sistemas que podem ser 
aplicadas em outros softwares, de diferentes contextos.
Essas abordagens de modelagem, com o intuito de 
solucionar um problema de modelagem são denominadas 
de Padrões de Projeto. Pressman e Maxim (2016) entendem 
como uma regra de três partes que expressa uma relação entre 
um contexto, um problema e uma solução.
A ideia por trás desse conceito começou a ser estabelecido 
no livro “A Pattern Language” de Christopher Alexander, 
Sara Ishikawa e Murray Silverstein. Nesse livro, os autores 
exemplificam	padrões	na	área	de	construção	civil,	informando	
ideias de como aplicar e organizar bairros, cidades etc.
Em 1994, foi entregue para a comunidade o primeiro 
trabalho catalogando os padrões de projeto, chamado de 
“Design Patterns: Elements of Reusable Object-Oriented 
Software”, escrito por Erich Gamma, Richard Helm, Ralph 
Johnson e John Vlissides. 
Esse livro se tornou um dos mais importantes da área, 
fazendo que os autores deste livro fossem conhecidos como 
“The	Gang	of	Four”	-	GoF.	A	sigla	GoF	passou	a	identificar	
também os 23 padrões listados neste livro. Esses padrões 
vieram de códigos reais.
Em sua obra, Guerra (s.d.) explica o que é um bom 
padrão:
Para ser um padrão, uma solução não basta ser 
recorrente, mas precisa ser uma boa solução 
(caso contrário é um anti-padrão). Além 
disso, é comum que ela traga outras partes, 
como a estrutura da solução, como funciona 
a sua dinâmica e as consequências positivas 
e negativas de sua aplicação. Outra parte 
importante é o relacionamento com os outros 
padrões, pois mostra outros que oferecem 
uma outra alternativa, ou padrões que podem 
complementar essa solução para compensar 
suas desvantagens. (GUERRA, s.d., p. 16)
 Além disso, Guerra também ressalta que o uso 
desenfreado de padrões, sem avaliar suas alternativas, pode 
causar problemas na manutenção do código.
 Nas próximas seções, vamos aprender os principais 
padrões de projeto orientado a objetos.
2 - Padrões de Projeto orientado a 
objetos
Como já vimos, o livro “Design Patterns: Elements of 
Reusable Object-Oriented Software” elenca 23 padrões de 
projetos. Esses padrões podem ser usados para projetar as 
classes em um projeto orientado a objetos, por isso a sua 
classificação.	Logo	após	a	publicação,	muitos	outros	padrões	
surgiram, mas os padrões originais foram os mais conhecidos 
e são os mais usados e estudados até hoje.
Nesse	 livro,	 esses	 padrões	 de	projeto	 são	 classificados	
em três grupos:
•	 padrões de criação: relacionados à criação de 
objetos;
•	 padrões estruturais: propõem soluções para 
associações entre classes;
•	 padrões comportamentais: tratam das interações e 
da divisão de responsabilidades.
Para você entender como funcionam esses padrões 
de projeto, vamos estudar seis padrões de projeto muito 
utilizados atualmente: Builder, Singleton, Adapter, Facade, 
Command e Strategy.
2.1 - Builder
É um padrão de criação que se propõe a resolver 
problemas na criação de instâncias de classes, principalmente, 
em classes com construtores muito complexos (muitos 
construtores ou construtores com muitos parâmetros). 
Construtor é o método que é executado toda vez que um 
novo objeto é criado.
Seu funcionamento é simples: ele apenas delega a parte 
da construção do objeto a uma classe separada, desacoplando 
a lógica de criação complexa da classe original, criando classes 
concisas.
A imagem a seguir representa o padrão Builder. A classe 
Cliente usa efetivamente o Builder para criar os produtos que 
precisa.
Figura 1 - Padrão Builder. Fonte: guErra, s.d, p. 131.
2.2 - Singleton
Esse padrão de criação é usado para classes onde só deve 
ser permitida apenas uma instância de execução em todo o 
programa. Sua estratégia é bem simples: o construtor tem a 
visibilidade privada, impedindo a sua execução por outros 
45
objetos. 
Para que outros objetos recebam a sua instância, cria-se 
um método estático (um método que pode ser executado sem 
precisar criar o objeto, invocado pelo nome da classe), que se 
encarrega de entregar a instância (e em caso de que o objeto 
não tenha sido criado, criar esta instância).
Figura 2 - Reprodução do código do padrão Singleton. Fonte: GUERRA, s.d, p. 128.
2.3 - Adapter
O Adapter (desta vez um padrão estrutural) funciona 
como se fosse um “adaptador”. Ele serve para situações 
em que um software já existente precisa adaptar-se a uma 
nova API de outra classe. Ao invés de que o software todo 
seja remodelado para poder usar a API, uma interface é 
criada para que a classe possa usufruir os recursos da outra 
classe.
Figura 3 - Diagrama uML do padrão adapter. Fonte: MEDEirOS, s.d.
2.4 - Facade
Esse padrão estrutural usa a analogia de uma fachada. 
Serve para isolar e abstrair o comportamento de um subsistema 
(pode ser uma ou várias classes, uma API, um framework etc.) 
para uma classe cliente. Uma classe de fachada é criada para 
abstrair esse comportamento.
Figura 4 - Diagrama uML do padrão Facade. Fonte: VEnTura, 2015.
2.5 - Command
Esse padrão comportamental serve para abstrair uma 
operação como uma classe. Assim, classes são criadas para 
apenas encapsular uma operação que pode ser executada pela 
mesma classe ou por outra classe, com o intuito de encapsular 
a API desta classe. Esses comandos podem ser usados para 
uma única execução ou por uma execução em lote. 
Cada classe de comando implementa a interface de classe 
de comando, fazendo que o executor aceite qualquer operação, 
desde que essa classe implemente a interface estabelecida.
Figura 5 - Estrutura do padrão Command em duas situações: (i) quando a classe 
que implementa é parte de um componente e (ii) quando a classe que implementa 
o padrão é parâmetro para a execução. Fonte: GUERRA, s.d, p. 167 - 168. Adaptado.
2.6 – Strategy
Nesse padrão é usado uma classe que utiliza diversos 
algoritmos de forma intercambiável. É criada uma classe para 
cada	 algoritmo,	 implementando	 uma	 interface	 especificada.	
Isso é interessante para situações que envolvem decisões de 
processamento através de condicionais. 
Figura 6 - Estrutura genérica do padrão Strategy. Fonte: CODE PROJECT, 2008.
Engenharia de Requisitos 46
determinadas etapas de um algoritmo sem alterar a estrutura do 
algoritmo.
•	 Visitor:represente uma operação a ser realizada nos elementos 
de	uma	estrutura	de	objetos.	O	padrão	Visitor	permite	que	se	defina	
uma nova operação sem alterar as classes dos elementos nos quais a 
operação age.
Os outros padrões goF
A seguir, vamos elencar os demais padrões elencados pela Gang of 
Four, descritos por Batistão (2016):
Padrões de Criação:
•	 Abstract Factory: provê uma interface para criar famílias de objetos 
relacionados	 ou	 interdependentes	 sem	 especificar	 suas	 classes	
concretas.
•	 Factory	Method:	 define	uma	 interface	 para	 criar	 um	objeto,	mas	
deixa as subclasses decidirem qual classe instanciar. o padrão Factory 
Method deixa uma classe repassar a responsabilidade de instanciação 
para subclasses.
•	 Prototype:	 especifica	 os	 tipos	 de	 objetos	 a	 criar	 usando	 uma	
instância-protótipo e cria novos objetos copiando este protótipo.
Padrões Estruturais:
•	 Adapter: converte a interface de uma classe em outra interface 
com a qual os clientes estão prontos para lidar. o padrão Adapter 
permite que classes trabalhem conjuntamente apesar de interfaces 
incompatíveis.
•	 Bridge: desacopla uma abstração de sua implementação de forma 
que as duas possam mudar independentemente uma da outra.
•	 Composite: compõe objetos em estruturas de árvore para 
representar hierarquias Parte-Todo. o padrão Composite permite 
que clientes tratem objetos individuais e composições de objetos de 
uniformemente.
•	 Decorator: adiciona responsabilidades a um objeto dinamicamente. 
Decoradores	provêem	uma	alternativa	flexível	à	herança	para	estender	
funcionalidade.
•	 Flyweight:	 usa	o	 compartilhamento	para	dar	 suporte	eficiente	ao	
uso	de	um	grande	número	de	objetos	de	granularidade	pequena.
•	 Proxy: provê um objeto procurador ou placeholder para um outro 
objeto para controlar o acesso a ele.
Padrões Comportamentais:
•	 Chain of Responsibility: evita acoplar o enviador de um pedido 
ao receptor dando oportunidade a vários objetos para tratarem do 
pedido. os objetos receptores são encadeados e o pedido é passado 
na cadeia até que um objeto o trate.
•	 Interpreter:	dada	uma	linguagem,	define	uma	representação	de	sua	
gramática e um interpretador que usa a representação da gramática 
para interpretar sentenças da linguagem.
•	 iterator: provê uma forma de acessar os elementos de uma coleção 
de objetos seqüencialmente sem expor sua representação subjacente.
•	 Mediator:	 define	 um	 objeto	 que	 encapsule	 a	 forma	 com	 a	 qual	
um conjunto de objetos interagem. o padrão Mediator promove 
o acoplamento fraco evitando que objetos referenciem uns aos 
outros explicitamente e permite que suas interações variem 
independentemente.
•	 Memento: sem violar o princípio de encapsulamento, captura e 
externaliza o estado interno de um objeto de forma a poder restaurar 
o objeto a este estado mais tarde.
•	 Observer:	define	uma	dependência	um-para-muitos	entre	objetos	
de forma a avisar e atualizar vários objetos quando o estado de um 
objeto muda.
•	 State: permite que um objeto altere seu comportamento quando 
seu estado interno muda. o objeto estará aparentemente mudando 
de classe com a mudança de estado.
•	 Template	 Method:	 define	 o	 esqueleto	 de	 um	 algoritmo	 numa	
operação, deixando que subclasses completem algumas das etapas. 
O	 padrão	 Template	 Method	 permite	 que	 subclasses	 redefinem	
3 - outros tipos de padrões de 
projeto
Pressman e Maxim (2016) citam outros tipos de padrões 
de projeto existentes:
•	 Padrões de arquitetura: descrevem problemas de 
projeto de caráter amplo e diverso, resolvidos 
usando-se uma abordagem estrutural;
•	 Padrões de dados: descrevem problemas orientados 
a dado recorrentes e as soluções para a modelagem 
de dados que podem ser usados;
•	 Padrões de componentes: tratam de problemas 
associados ao desenvolvimento de subsistemas 
e componentes, englobando a maneira que se 
comunicam entre si. Eles não dão soluções 
comprovadas que tratam de um ou mais 
subproblemas extraídos do modelo de requisitos, 
podendo se concentrar em algum elemento 
funcional do sistema;
•	 Padrões de projeto para interfaces: tratam 
de soluções para interfaces de usuário, como 
breadcrumbs, FAQ etc.
4 - Aplicando os padrões de projeto
Nesta aula você teve uma breve introdução sobre os 
padrões de projeto. Mas o que devemos fazer para aplicá-los 
na prática?
Há duas formas de aplicar padrões de projeto. Uma delas 
é	a	análise	de	requisitos	e	de	projeto,	para	verificar	se	alguma	
parte se encaixa em um padrão de projeto. Pressman e Maxim 
(2016) elencam uma série de tarefas a serem feitas:
1. Examine o modelo de requisitos e desenvolva uma 
hierarquia de projeto, descrevendo cada problema 
e subproblema isolando o problema. Comece 
descrevendo problemas mais abrangentes. À medida 
que você descreve esses projetos, você descreve os 
projetos mais detalhados;
2. Determine	se	uma	linguagem	de	padrões	confiável	
foi desenvolvida para o domínio de problema. 
Existem certas situações (como sites de comércio 
eletrônico) que possuem padrões próprios. O 
projetista	 deve	 fazer	 uma	 pesquisa	 para	 verificar	
se existem padrões para sistemas com o domínio 
de problema. Caso contrário, devem ser usados os 
padrões de projetos para sistemas genéricos;
3. Iniciando com um problema abrangente, determine 
se um ou mais padrões de arquitetura se encontram 
disponíveis para ele;
4. Use as colaborações fornecidas para o padrão de 
47
arquitetura, examine problemas de subsistemas ou 
de componentes e procure padrões apropriados 
para tratar deles;
5. Repita os três passos anteriores até que todos os 
problemas mais amplos sejam tratados;
6. Se os problemas de projeto para interfaces do 
usuário tiverem sido isolados, pesquise os vários 
repositórios de padrões de projetos para interfaces 
de usuário em busca de padrões apropriados, 
fazendo os passos 3, 4 e 5;
7. Independente de seu nível de abstração, se uma 
linguagem de padrões e/ou repositório de padrões 
de projetos ou padrão individual se mostrar 
promissor, compare o problema o problema a ser 
resolvido em relação ao(s) padrão(ões) existente(s) 
apresentado(s);
8. Certifique-se	 de	 refinar	 o	projeto	 à	medida	 que	 é	
obtido de padrões usando os critérios de qualidade 
de projeto como guia.
Como encontrar padrões de projeto
Existem vários sites na internet que atuam como repositórios de 
padrões de projeto. Vejamos alguns deles:
•	 The Hillside Group: <http://www.hillside.net/patterns>. (em inglês)
•	 C2 Pattern Index: <http://wiki.c2.com/?PatternIndex>. (em inglês)
•	 Catálogo de Padrões de Projeto: <http://www.dpi.ufv.br/
projetos/apri/?page_id=519>.
•	 Welie Patterns In Interaction Design: <http://www.welie.com/
patterns/>. (em inglês)
Existem vários outros sites com essa função. Recomendamos que 
você pesquise alguns deles. Muitos desses sites são em Inglês, mas 
são muito bem documentados.
Em relação aos padrões GoF, eles podem ser aplicados 
no processo de construção do sistema, durante um processo 
de refatoração, como citado por Brizeno:
A principal dica para utilizar Padrões de 
Projeto	de	maneira	eficiente	é:	evite	escrever	
código aplicando um Padrão de Projeto, 
prefira	refatorar	para	um	padrão.	Se	o	código	
não	 precisa	 da	 flexibilidade	 proporcionada	
pelos padrões, evite complicá-lo.
Deixe que seu código evolua e que as regras de 
negócio lhe digam o que deve ser melhorado. 
Quem desenvolve utilizando TDD (Test-
Driven Development) pode pensar em aplicar 
um padrão durante a etapa de refatoração, pois 
terá mais entendimento dos requisitos e da 
implementação necessária, além da segurança 
dos testes automatizados.
Antes de decidir refatorar o código para aplicar 
um Padrão de Projeto, veja quais princípios 
ele está ferindo e tente fazer correções mais 
simples. Não se torne um dicionário de 
padrões, forçandosituações para aplicá-los. 
Pense no contexto do seu problema primeiro e 
depois na solução que irá aplicar. (BRIZENO, 
2016)
E,	 com	 isso,	 finalizamos	 a	 nossa	 aula	 de	 Padrões	
de Projeto. Na próxima aula, vamos falar de negociação, 
gerenciamento e validação de requisitos.
Retomando a aula
Chegamos	 ao	 final	 da	 nossa	 sexta	 aula,	 que	
abordamos os Padrões de Projeto. Vamos recordar 
os pontos principais?
1 - Padrões de Projeto
Padrão de projeto é entendido como uma solução boa para 
certo problema. É entendido como uma regra de três partes que 
expressa uma relação entre um contexto, um problema e uma 
solução.	Gamma	et	al.	fizeram	o	primeiro	catálogo	de	padrões	
de projeto, iniciando a disseminação da prática.
2 - Padrões de Projeto Orientado a Objetos
Você viu que os padrões de projetos GoF se encaixam 
em três categorias: Padrões de Criação (Relacionados à 
criação de objetos), Padrões Estruturais (Propõem soluções 
para associações entre classes) e Padrões Comportamentais 
(tratam das interações e da divisão de responsabilidades). 
Você viu também os padrões Builder, Singleton, Adapter, 
Facade, Command e Strategy.
3 - Outros tipos de padrões de projeto
Depois do trabalho da Gang of Four, vários outros 
padrões surgiram, e podem ser catalogados como: padrões 
de arquitetura, padrões de dados, padrões de componentes e 
padrões de projeto para interfaces.
4 - Aplicando os padrões de projeto
Vimos que os padrões de projeto podem ser aplicados de 
duas formas: a primeira é por meio de uma análise de requisitos 
e	na	arquitetura	do	sistema,	para	verificar	se	algum	problema	
do sistema pode ser resolvido com um padrão de projeto. Ou 
pode ser aplicado durante as refatorações de um código.
Vale a pena
BRIZENO, Marcos. Primeiros passos com Padrões de 
Projeto. [S.l.]: LeanPub, 2016.
GUERRA, Eduardo. Design Patterns com Java: Projeto 
orientado a objetos guiado por padrões. São Paulo: Casa do 
Código, s.d.
PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia 
de Software: Uma	abordagem	profissional.	8	ed.	Porto	Alegre:	
Bookman, 2016. 
Vale a pena ler
Engenharia de Requisitos 48
BATISTÃO, Carlos E. Z. Design Patterns. [S.l.]: 
Desenvolvendo no dia a dia, 2016. Disponível em: 
<https://cezbatistao.wordpress.com/2016/05/21/design-
patterns/>. Acesso em: 14 mar. 2018.
CODE PROJECT. Most Commonly Used Design Pattern. 
2008. Disponível em: <https://www.codeproject.com/
Articles/29729/Most-Commonly-Used-dEsign-pAttern>. 
Acesso em: 14 mar. 2018.
DESIGN Patterns Library. [S.l.]: The Hillside Group, 
s.d. Disponível em: <http://www.hillside.net/patterns>. 
Acesso em: 14 mar. 2018.
MEDEIROS, Higor. Padrão de Projeto Adapter em 
Java. [S.l.]: DevMedia, s.d. Disponível em: <https://
www.devmedia.com.br/padrao-de-projeto-adapter-em-
java/26467>. Acesso em: 14 mar. 2018.
UFV. Catálogo De Padrões De Projeto. [S.l.]: UFV, 
s.d. Disponível em: <http://www.dpi.ufv.br/projetos/
apri/?page_id=519>. Acesso em: 14 mar. 2018.
PATTERN Index. [S.l.]: Cunningham & Cunningham, Inc.. 
s.d. Disponível em: <http://wiki.c2.com/?PatternIndex>. 
Acesso em: 14 mar. 2018.
VENTURA, Plínio. Design Pattern Facade. [S.l.]: 
Até o Momento, 2015. Disponível em: <http://www.
ateomomento.com.br/facade-padrao-de-projeto/>. 
Acesso em: 14 mar. 2018.
WELIE, Martijn Van. Pattern Library. [S.l.]: Welie.com, 
s.d. Disponível em: <http://www.welie.com/patterns/>. 
Acesso em: 14 mar. 2018.
Vale a pena acessar
Minhas anotações