ARQUITETURA

DESENVOLVIMENTO WEB
Design Patterns
Viu algum erro neste material? Contate-nos em: degravacoes@grancursosonline.com.br
DESIGN PATTERNS
Referências:
O livro à esquerda é clássico da matéria. É calcado em C++. O da direita é baseado em

Java. Os dois são livros grandes (cerca de 600 páginas).
5m
INTRODUÇÃO
Os design patterns (padrões de projeto) representam as melhores práticas usadas por

desenvolvedores experientes de software orientados a objetos. É um compilado para solu-
ções de problemas conhecidos. São soluções para problemas gerais enfrentados pelos
desenvolvedores de software durante o desenvolvimento do software.
Essas soluções foram obtidas por tentativa e erro por vários desenvolvedores de sof-
tware durante um período substancial de tempo. Os design patterns estão entre a arquitetura
geral e a linguagem de programação. Podem ser compostos em conjunto.
10m
Além disso, são independentes de linguagens, ou seja, podem ser usados em qualquer
linguagem.
ANOTAÇÕES
1 www.grancursosonline.com.br
DESENVOLVIMENTO WEB
Design Patterns
Gang of Four (GoF)

Em 1994, quatro autores (Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides)
publicaram um livro intitulado Design Patterns — Elementos de Software Orientado a Obje-
tos Reutilizáveis que iniciou o conceito de Design Pattern no desenvolvimento de Software.
Esses autores são conhecidos coletivamente como Gang of Four (GoF). Segundo esses
autores, os padrões de design são baseados principalmente nos seguintes princípios de
design orientado a objetos:
→ Favorecer a composição do objeto sobre a herança;
→ Programar para uma interface, não uma implementação;
HERANÇA
De modo simplificado, herança é “uma classe (classe filha) que tem os mesmos atributos
de outra (classe pai), mais alguns atributos distintos”.
Exemplo: uma classe cliente, que é a classe principal, e duas classes filhas da classe
principal, “Pessoa Física” e “Pessoa Jurídica”.
Neste exemplo, as duas classes podem ser entendidas como um cliente, mas cada uma
com alguns atributos a mais:
Benefícios e Problemas da Herança

No começo, a herança era muito usada, e surgiram hierarquias complexas. O uso da
herança, então, fugiu do controle.
Um dos benefícios da herança é que ela captura o que é comum e isola aquilo que é
diferente. Além disso, a herança é percebida diretamente no código, até mesmo devido à sua
natureza estática.
15m
DESENVOLVIMENTO WEB
Design Patterns
Entre os problemas da herança está o fraco encapsulamento entre classes e subclasses

e o forte acoplamento entre elas, de forma que mudar uma superclasse pode afetar todas
as subclasses, além de violar o princípio básico de projeto OO em que devemos ter sempre
um baixo acoplamento entre as classes. A mudança em uma classe gera, automaticamente,
mudanças nas subclasses.
Além disso, algumas vezes um objeto precisa ser de uma classe diferente em momentos
diferentes, o que não é possível com a herança, pois o código não pode sofrer alterações
facilmente em tempo de execução. Portanto, entende-se que a herança é um relaciona-
mento estático.
COMPOSIÇÃO
Composição é bem mais simples de entender que a herança. Ela acontece quando uma
determinada classe A está contida em outra determinada classe B.
Exemplo: imagine duas classes distintas, sendo que a primeira é a classe Carro e a
segunda é a classe Motor. Imagine que toda classe Carro tenha uma classe Motor. Neste
exemplo há uma relação de composição entre Carro e Motor, pois o motor está contido na
classe Carro.
A seta fechada significa que o carro possui um motor.

Como os carros podem ter diferentes tipos de motores, basta trocar apenas o motor, já
que o resto do carro continua igual.
Benefícios e Problemas da Composição

A grande vantagem da composição é que o comportamento pode ser escolhido em tempo
de execução em vez de estar amarrado ao tempo de compilação.
20m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns
Além disso, os objetos que foram instanciados e estão contidos na classe que os instan-
ciou são acessados somente através de sua interface, seguindo assim o princípio de progra-
mar para uma interface e não para uma implementação.
A composição também apresenta uma menor dependência de implementações e temos
cada classe focada em apenas uma tarefa, seguindo o princípio da responsabilidade única.
Por fim, a composição também tem um bom encapsulamento, em que os detalhes inter-
nos dos objetos instanciados não são visíveis.
A grande desvantagem é que um software muito dinâmico e parametrizado é mais difícil
de entender do que software mais estático.
Quando Usar Composição ou Herança

De forma geral, prefira utilizar sempre a composição em relação à herança. No entanto,
pode-se definir algumas regras para identificar quando podemos usar a herança de forma
que não tenhamos os problemas que ela acarreta.
Utiliza-se a herança se uma instância de uma classe filha nunca precisar se tornar um
objeto de outra classe, se a hierarquia de herança representar um relacionamento “é um” e
não um relacionamento “tem um”. A herança pode ser utilizada para realizar alterações glo-
bais para as suas classes filhas alterando uma classe pai, ou então quando a classe filha
estende, ao invés de substituir total ou parcialmente, as responsabilidades da classe pai.
PLATAFORMA COMUM PARA DESENVOLVEDORES
Os padrões de projeto fornecem uma terminologia padrão e são específicos para um

determinado cenário. Os softwares têm se tornado mais e mais complexos, com bilhões de
linhas de código. Seria difícil um desenvolvedor, que entrou durante o projeto, absorver todo
esse conhecimento desde o início. Ficará mais fácil se ele puder reconhecer a programação
de outros projetos.
Por exemplo, um padrão de projeto singleton significa o uso de um único objeto, para que
todos os desenvolvedores familiarizados com o padrão de projeto único utilizem um único
objeto e possam dizer um ao outro que o programa está seguindo um padrão singleton.
25m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns
MELHORES PRÁTICAS
Os padrões de projeto foram desenvolvidos durante um longo período de tempo e forne-

cem as melhores soluções para certos problemas enfrentados durante o desenvolvimento
de software.
O aprendizado desses padrões ajuda os desenvolvedores inexperientes a entender o
design de software de maneira fácil e rápida.
É possível aprender com os erros já cometidos e evitar que esses equívocos ocorram
novamente.
TIPOS DE PADRÕES DE PROJETO
De acordo com o livro Design Patterns – Elementos de Software Orientado a Objetos

Reutilizáveis, existem 23 padrões de projeto que podem ser classificados em três categorias:
1. Padrões de criação
2. Estruturais
3. Comportamentais
Padrões de Criação: esses padrões de design fornecem uma maneira de criar objetos
enquanto ocultam a lógica de criação, em vez de instanciar objetos diretamente usando o
operador new. Isso dá ao programa mais flexibilidade para decidir quais objetos precisam ser
criados para um determinado caso de uso.
Padrões Estruturais: esses dizem respeito à classe e à composição do objeto. O con-
ceito de herança é usado para compor interfaces e definir maneiras de compor objetos para
obter novas funcionalidades.
Padrões Comportamentais: já esses se preocupam especificamente com a comunica-
ção entre objetos.
DIRETO DO CONCURSO
1. (2019/CESPE/MPC/PA/ANALISTA MINISTERIAL/TECNOLOGIA DA INFORMA-
ÇÃO) Assinale a opção que apresenta os três grupos em que se segmentam os De-
sign Patterns.
a. Padrões de criação, padrões estruturais e padrões comportamentais.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns
b. Padrões de análise, padrões estruturais e padrões comportamentais.

c. Padrões de criação, padrões de construção e padrões comportamentais.
d. Padrões de criação, padrões estruturais e padrões de construção.
e. Padrões de análise, padrões de construção e padrões comportamentais.
COMENTÁRIO
Padrões de Criação: esses padrões de design fornecem uma maneira de criar objetos
enquanto ocultam a lógica de criação, em vez de instanciar objetos diretamente usando o
operador new. Isso dá ao programa mais flexibilidade para decidir quais objetos precisam
ser criados para um determinado caso de uso.
Padrões Estruturais: esses padrões de design dizem respeito à classe e à composição
do objeto. O conceito de herança é usado para compor interfaces e definir maneiras de
compor objetos para obter novas funcionalidades.
Padrões Comportamentais: esses padrões de design se preocupam especificamente
com a comunicação entre objetos.
GABARITO
1. a
�Este material foi elaborado pela equipe pedagógica do Gran Cursos Online, de acordo com a aula
preparada e ministrada pelo professor Tiago Lage Payne de Pádua.
A presente degravação tem como objetivo auxiliar no acompanhamento e na revisão do conteúdo
ministrado na videoaula. Não recomendamos a substituição do estudo em vídeo pela leitura exclu-
siva deste material.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
DESIGN PATTERNS II
FACTORY / FÁBRICA
Vamos mostrar os tipos de design patterns com os nomes em inglês e em português. Nas
provas, têm sido cobrado o nome em inglês.
O padrão de fábrica é um dos padrões de design mais usados em Java. Esse tipo de
padrão de design se enquadra no padrão criacional, pois fornece uma maneira de criar
um objeto.
No padrão Factory, criamos objetos sem expor a lógica de criação ao cliente e nos refe-
rimos ao objeto recém-criado usando uma interface comum.
A ShapeFactory vai retornar uma shape (uma interface, que pode ser um retângulo, um
quadrado ou um círculo).
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
5m
A programação acima representa o lado esquerdo do organograma.
Na sequência, está a parte direita do esquema.
DESENVOLVIMENTO WEB
Design Patterns II
O código abaixo mostra o que está consumindo a factory:
Não é obrigado a ter factory no nome, mas é bom descrever a classe para que outro
desenvolvedor possa identificá-la.
ABSTRACT FACTORY / FÁBRICA ABSTRATA
Os padrões de fábrica trabalham em torno de uma superfábrica que cria outras fábricas.
Esta fábrica também é chamada de fábrica de fábricas. Esse tipo de padrão de design se
enquadra no padrão criacional, pois fornece uma maneira de criar um objeto.
No padrão Abstract Factory, uma interface é responsável por criar uma fábrica de objetos
relacionados sem especificar explicitamente suas classes. Cada fábrica gerada pode forne-
cer os objetos conforme o padrão de fábrica.
É pouco usada na prática da programação. É mais elaborada do que a fábrica simples,

como pode ser visto abaixo. Se aparecer um FactoryProducer, então é uma fábrica abstrata.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
10m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
SINGLETON
O Singleton é um dos padrões de design mais simples em Java. Esse tipo de padrão de
design se enquadra no padrão criacional.
Esse padrão envolve uma única classe responsável por criar um objeto, assegurando
que apenas um único objeto seja criado. Essa classe fornece uma maneira de acessar seu
único objeto que pode ser acessado diretamente sem a necessidade de instanciar o objeto
da classe.
Exemplo: quando queremos compartilhar informações num mesmo sistema.

15m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
BUILDER / CONSTRUTOR
O padrão Builder cria um objeto complexo usando objetos simples e usando uma aborda-
gem passo a passo. Esse tipo de padrão de design se enquadra no padrão criacional.
Uma classe Builder cria o objeto final passo a passo. Este construtor é independente de
outros objetos.
20m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
PROTOTYPE / PROTÓTIPO
O padrão de protótipo refere-se à criação de objetos duplicados, mantendo o desempe-

nho em mente. Esse tipo de padrão de design se enquadra no padrão criacional.
Esse padrão envolve a implementação de uma interface de protótipo que informa para
criar um clone do objeto atual. Esse padrão é usado quando a criação do objeto diretamente
é cara. Por exemplo, um objeto deve ser criado após uma operação cara do banco de dados.
Podemos armazenar em cache o objeto, retornar seu clone na próxima solicitação e atualizar
o banco de dados conforme e quando necessário, reduzindo assim as chamadas ao banco
de dados.
25m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
DIRETO DO CONCURSO
1. (UF-MA/UF-MA/ANALISTA DE TECNOLOGIA DA INFORMAÇÃO/2019) De acordo com
Gamma, padrões de projeto são soluções reutilizáveis de software orientado a objetos.
Considere as três afirmativas a seguir e depois informe a alternativa correta.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
I – Padrões de projeto de criação são aqueles que abstraem o processo de instanciação

de objetos.
II – Padrões de projeto estruturais se preocupam com a forma como classes e objetos
são compostos para formar estruturas maiores.
III – Padrões de projeto comportamentais se preocupam com algoritmos e a atribuição de
responsabilidades entre objetos.
a. Apenas a afirmativa I está correta.
b. Apenas as afirmativas I e II estão corretas.
c. Apenas as afirmativas I e III estão corretas.
d. Apenas as afirmativas II e III estão corretas.
e. As três afirmativas estão corretas.
COMENTÁRIO
I – Não é usado o new e o usuário passa à outra classe a criação do objeto.
II – Os padrões miram a forma para compor padrões maiores.
III – Os padrões comportamentais se preocupam com a comunicação.
2. (INAZ DO PARÁ/CORE-SP/ANALISTA DE T.I/2019) “Em 1995 Erich Gama, Richard

Helm, Ralph Johnson, John Vlissides, conhecidos como os quatro amigos [Gang of
Four - GoF], publicaram o livro sobre o título: “Design patterns — elements of reusable
object-oriented software, Addison Wesley Longman”, que ganhou uma versão na língua
portuguesa sobre o título de “Padrões de Projeto – Soluções reutilizáveis de software
orientado a objetos. Bookman”.
Disponível em: https://www.devmedia.com.br/conheca-os-padroes-de-projeto/957. Acesso em:
13.12.2018
Qual padrão de projeto tem o propósito de assegurar o controle da quantidade de ins-

tâncias da classe?
a. Singleton.
b. Façade.
c. Proxy.
d. MVC.
e. Command.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns II
COMENTÁRIO
Singleton: O padrão Singleton é um dos padrões de design mais simples em Java. Esse
tipo de padrão de design se enquadra no padrão criacional. Esse padrão envolve uma
única classe responsável por criar um objeto, assegurando que apenas um único objeto
seja criado. Essa classe fornece uma maneira de acessar seu único objeto que pode ser
acessado diretamente sem a necessidade de instanciar o objeto da classe.
GABARITO
1. e
2. a
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
DESIGN PATTERNS III
ADAPTER / ADAPTADOR
O padrão do adaptador funciona como uma ponte entre duas interfaces incompatí-
veis. Esse tipo de padrão de design se enquadra no padrão estrutural, pois combina a capa-
cidade de duas interfaces independentes.
Esse padrão envolve uma única classe responsável por unir funcionalidades de
interfaces independentes ou incompatíveis.
Um exemplo da vida real pode ser um caso de leitor de cartão que atua como um adap-
tador entre o cartão de memória e um laptop. Você pluga o cartão de memória no leitor de
cartões e o leitor de cartões no laptop para que o cartão de memória possa ser lido via laptop.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
5m
DESENVOLVIMENTO WEB
Design Patterns III
É uma construção rebuscada, dando suporte ao mp3, ao mp4 e ao vlc.
Independente da complexidade, na hora da utilização será simples, sem a preocupação

de ligar os players diferentes. O adapter fará isso.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
BRIDGE / PONTE
É usado quando precisamos separar uma abstração de sua implementação para que
as duas possam variar independentemente. Esse tipo de padrão de design se enquadra no
padrão estrutural, pois desacopla a classe de implementação e a classe abstrata, fornecendo
uma estrutura de ponte entre eles.
Esse padrão envolve uma interface que atua como uma ponte que torna a funciona-
lidade de classes concretas independente das classes do implementador de interface.
Ambos os tipos de classes podem ser alterados estruturalmente sem se afetarem.
10m
DESENVOLVIMENTO WEB
Design Patterns III
FILTER / FILTRO
O padrão de filtro ou Criteria é um padrão de design que permite aos desenvolvedores

filtrar um conjunto de objetos usando diferentes critérios e encadeando-os de maneira disso-
ciada por meio de operações lógicas.
Esse tipo de padrão de design se enquadra no padrão estrutural, pois combina vários
critérios para obter critérios únicos.
Bastante visto em programação Java, como criteria API.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
15m
DESENVOLVIMENTO WEB
Design Patterns III
O código recebe dois critérios na entrada, e vai selecionando os dados conforme o aten-
dimento aos critérios.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
COMPOSITE / COMPOSIÇÃO
O padrão de composição é usado onde precisamos tratar um grupo de objetos de maneira

semelhante a um único objeto. O padrão compõe objetos em termos de uma estrutura em
árvore para representar parte e toda a hierarquia. Esse tipo de padrão de design se enquadra
no padrão estrutural, pois cria uma estrutura em árvore do grupo de objetos.
20m
Esse padrão cria uma classe que contém um grupo de seus próprios objetos. Esta classe
fornece maneiras de modificar seu grupo dos mesmos objetos.
É um dos mais simples.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
DESENVOLVIMENTO WEB
Design Patterns III
DIRETO DO CONCURSO
1. (2018/UFPR/UFPR/TÉCNICO DE TECNOLOGIA DA INFORMAÇÃO) Em relação aos
Padrões de Projeto, é correto afirmar que:
a. o Adapter permite que classes com interfaces incompatíveis trabalhem em conjunto.

b. o Bridge permite compor objetos em estruturas de árvore para representar hierar-
quias todo-parte.
c. o Singleton desacopla uma abstração de sua implementação.
d. o Observer define uma interface para criar um objeto.
e. o Factory Method possibilita anexar responsabilidades adicionais a um objeto
dinamicamente.
COMENTÁRIO
a. Adapter / Adaptador: o padrão do adaptador funciona como uma ponte entre duas in-
terfaces incompatíveis. Esse tipo de padrão de design se enquadra no padrão estrutural,
pois combina a capacidade de duas interfaces independentes. Esse padrão envolve uma
única classe responsável por unir funcionalidades de interfaces independentes ou
incompatíveis. Um exemplo da vida real pode ser um caso de leitor de cartão que atua
como um adaptador entre o cartão de memória e um laptop. Você pluga o cartão de memó-
ria no leitor de cartões e no leitor de cartões no laptop para que o cartão de memória possa
ser lido via laptop.
b. Composite / Composição: o padrão de composição é usado onde precisamos tratar um
grupo de objetos de maneira semelhante a um único objeto. O padrão compõe objetos
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns III
em termos de uma estrutura em árvore para representar parte e toda a hierarquia.

Esse tipo de padrão de design se enquadra no padrão estrutural, pois cria uma estrutura
em árvore do grupo de objetos.
c. Bridge / Ponte: é usado quando precisamos separar uma abstração de sua imple-
mentação para que as duas possam variar independentemente. Esse tipo de padrão
de design se enquadra no padrão estrutural, pois desacopla a classe de implementação e
a classe abstrata, fornecendo uma estrutura de ponte entre eles.
d. É a descrição do Factory method.
e. É a descrição do Decorator.
GABARITO
1. a
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
DESIGN PATTERNS IV
DESIGN PATTERNS – PADRÕES DE PROJETO
Decorator / Decorador
O padrão decorador permite que um usuário adicione novas funcionalidades a um objeto
existente sem alterar sua estrutura.
Obs.: Sugere-se que o aluno relacione o nome do Patterns com a característica dele, pois,
de fato, o Decorator vai decorar um objeto “sem alterar sua estrutura”.
Esse tipo de padrão de design se enquadra no padrão estrutural, visto que atua como um
invólucro para a classe existente;
Esse padrão cria uma classe decoradora que agrupa a classe original e fornece funcio-
nalidade adicional, mantendo intacta a assinatura dos métodos de classe;
Obs.: Uma característica importante é manter intacta a assinatura dos métodos de classe.
Diagrama – Programa DecoratorPatternDemo

ANOTAÇÕES
www.grancursosonline.com.br 1
DESENVOLVIMENTO WEB
Design Patterns IV
Obs.: ShapeDecorator é uma interface implementada pela RedShapeDecorator, a

classe concreta.
Exemplo:
Em termos de códigos: há uma interface Shape, um retângulo, um círculo e o Decorator.

O Decorator é uma classe abstrata que implementa também o Shape.
O ShapeDecorator receberá uma forma decorada e no seu construtor ganhará o formato

decorado. Quando ele utilizar o método Draw acionará o decorateShape.draw.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Tem-se aqui o RedShapeDecorator que estende o ShapeDecorator, recebendo uma

forma e dando um Override no método Draw. Assim, ele fará um desenho na forma que foi
decorado e ajustará a margem para vermelha (“Border Color Red”).
É perceptível que houve a preservação da mesma interface chamada Draw. Esse método
fará mais outra coisa além do Draw na forma que foi decorada, o setRedBorder. É aqui que
está o Sênior do Decorator. Ele faz o que a classe faria originalmente com o mesmo método
e mais alguma coisa, decorando aquele método e classe.
Na implementação, como um todo do programa DecoratorPatterDemo, há um círculo e

um redcircle, redShapeDecorator (new Circle). Dessa forma, tem-se um círculo normal, que é
um Shape, e outro Shape que é um redcircle. Em outras palavras, ambos são Shapes, mas o
redShapeDecorator receberá um próprio Shape no construtor dele. Essa é a forma que será
5m decorada.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
No Shape redRectabgle, tem-se a mesma situação. Então, será impresso o círculo normal
(circle.draw), depois o círculo com a borda vermelha (redCircle.draw) e, por fim, o retângulo
com a borda vermelha (redRectangle.draw).
A saída desse programa será o círculo com borda normal, depois o círculo com a borda
vermelha e, finalmente, o retângulo com a borda vermelha.
Esse é um exemplo de Decorator, que é bastante comum no desenvolvimento de Java. O
ponto principal dele é que tanto o Shape Circle quanto o redCircle são Shapes. No entanto,
o redCircle receberá a própria Shape interiormente.
O próximo padrão apresentado é também muito usual: trata-se do padrão de fachada.
Facade / Fachada
O padrão de fachada oculta as complexidades do sistema e fornece uma interface para o
cliente, permitindo que o cliente possa acessar o sistema. Esse tipo de padrão de design se
enquadra no padrão estrutural, pois adiciona uma interface ao sistema existente para ocultar
suas complexidades. Portanto, trata-se de um sistema complexo que se torna mais simples
de utilizar, no qual essa complexidade é oculta por uma fachada, como o nome sugere.
Esse padrão envolve uma única classe que fornece métodos simplificados exigidos pelo
cliente e delega chamadas para métodos de classes de sistema existentes. Em outras pala-
vras, existe uma classe em que será possível fazer uma chamada mais simples. Ela poten-
cialmente fará uma série de outras chamadas mais complexas internamente, fornecendo
uma fachada que simplificará a utilização do sistema.
Diagrama – Programa FacadePatternDemo

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Novamente, tem-se o Shape, o Circle, o Rectangle e também o Square. Do outro lado,

existe o padrão de fachada e o ShapeMaker, ou seja, o construtor de formas. Nele, encontra-
-se o drawCircle, o drawRectangle e o drawSquare.
Exemplo:

Há aqui uma interface Shape com o retângulo, o quadrado e o círculo. Observa-se o que
ocorre com o ShapeMaker:
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Essa classe internamente possui o círculo, o retângulo e o quadrado. Quando ela estiver
construída e for chamado o seu construtor, será feito um círculo, um retângulo e um qua-
drado. Assim, o ShapeMaker chamará o método drawCircle, que demandará o circle.draw, o
rectangle.draw no drawRectangle e o drawSquare no square.draw.
Torna-se notória a existência de somente uma classe, o ShapeMaker. Porém, interna-
mente a ela, existem três outras classes distintas. Então, ela se responsabiliza por criar as
instâncias dessas classes. Dessa forma, no momento em que é chamado o método drawCir-
cle, drawRectangle e drawScare, convoca-se o método draw do objeto correto interno dele.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Há, nessa parte, a execução do sistema FacadePatternDemo. Nela, seriam necessários

três objetos, mas com a fachada do shapeMaker podem-se chamar três métodos, drawCir-
cle, drawRectangle e drawSquare, sendo que ele será o responsável pelo draw do círculo,
10m do retângulo e do quadrado.
Portanto, o padrão facade relaciona-se à simplificação, isto é, a simplificar uma interface,
uma chamada de método.
Flyweight
O padrão Flyweight é usado principalmente para reduzir o número de objetos criados,
diminuir o espaço ocupado na memória e aumentar o desempenho. Esse tipo de padrão de
design se enquadra no padrão estrutural, pois fornece maneiras de diminuir a contagem de
objetos, melhorando assim a estrutura do aplicativo.
Obs.: Para cada um desses Patterns, há palavras-chave que se relacionam e vão aparecer
nas questões de concurso. Por exemplo, Facade liga-se à diminuição da complexida-
de e Flyweight à economia de memória. Dessa forma, pode se dizer que, para cada
problema que ocorra durante o desenvolvimento de um sistema, existirão Patterns
mais adequados para a situação.
O padrão Flyweight tenta reutilizar objetos do tipo semelhantes já existentes, armaze-

nando-os e criando um novo objeto, quando nenhum objeto correspondente é encontrado. O
padrão será demonstrado desenhando 20 círculos de locais diferentes, mas criando apenas
5 objetos. Somente 5 cores estão disponíveis, portanto, a propriedade color é usada para
verificar os objetos Circle já existentes.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Diagrama – Programa FryWeightPatternDemo
Há aqui a interface do Shape e o Circle. Do outro lado, o FlyWeightPattern, que é o pro-

grama. Nele, tem-se posto uma cor aleatória, um ponto X e um Y no método principal. Logo
abaixo, há uma fábrica de círculos.
Exemplo:
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Nesse exemplo há a Interface Shape, um Circle, que implementa o Shape, e onde ele vai
ter uma cor ponto x, y, raio e um consultor, além de um método de desenhar. Nesse método
poderá ser escrito o draw, a cor, o ponto x, y e o raio do círculo. Para construir essas formas
existe o ShapeFactory.
O primeiro passo na Factory é o HashMap, no qual está toda a chave do método. Esse
HashMap serve como um cache, uma memória especial para o círculo. O HashMap funciona
como uma árvore de hash, no qual é possível armazenar uma chave valor K/V. Depois de
chamar essa chave, novamente será obtido o valor armazenado nesse lugar.
O método getCircle se encontra com uma determinada cor, então ele vai obter, por meio
dessa cor, o Circle. Caso este seja nulo, ele criará um novo círculo com a cor, colocará o
círculo no Hashmap, expressará isso e retornará ao círculo. Em síntese, o método vai tentar
buscar no cache o círculo, caso não seja possível, será criado um círculo que depois será
colocado no cache, isso porque, em um próximo acionamento desse método, se ele já existir,
o cache vai ser recuperado. Vale ressaltar que o cache também se mantém com uma carac-
15m terística estética, ou seja, ele vai continuar existindo entre as chamadas do ShapeFactory.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
O programa FlyweightPatternDemo, de maneira geral, coloca uma lista de cores (Red,

Green, Blue, White e Black) e faz uma interação de 0 a 19 (20 itens), criando um getCircle
de uma cor aleatória. Essa cor é buscada dentro da lista de cores disponíveis para dese-
nhar o círculo. Assim, para cada círculo e cor, ele guarda no HashMap, sendo necessário,
posteriormente, ajustar o x, o y e o raio e desenhar o círculo. Pode-se dizer, portanto, que o
FlyweightPatternDemo está relacionado ao cache e à economia de memória para a criação
de objetos.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
A execução desse programa Java cria objetos, conforme a necessidade. Populando o

cache, ele não precisa criar os objetos novamente.
Proxy
No padrão de proxy, uma classe representa a funcionalidade de outra classe. Esse tipo
de padrão de design está sob um padrão estrutural. Nessa interface, cria-se um objeto que
possui o objeto original para fazer a interface de sua funcionalidade com o mundo exterior.
O padrão Proxy retoma o proxy de internet. Por exemplo, uma empresa poderá configu-
rar o navegador para acessar à internet por meio do Proxy, que é a sua interface. O proxy se
torna uma barreira e pode impedir o acesso a sites maliciosos, fazendo uma série de políticas
importantes para uma empresa, assim como evitar que haja acessos indevidos e tentativas
de invasão.
Diagrama – Programa ProxyPatterDemo
Pode haver, nesse programa, uma Image, que é uma interface, uma RealImage e uma
Proxyimagem. Ambas implentam a interface image. Então, o ProxyPatterDemo utiliza a Pro-
xyImage. Exemplo:
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Observa-se aqui a Image (Inteface) e a RealImage que a implementa. No momento da

criação da RealImage, é recebido o fileName (this.fileName é o nome do arquivo), e ele faz
um método chamado loadFromDisk.
O ProxyImage implementa Image, mas internamente ele tem uma RealImage e um file-
Name. O ProxyImage recebe o fileName e, quando faz o display e a realImage está igual a
null, ele busca a imagem real do fileName para, em seguida, realizar o realImage.display.
Em outras palavras, ele faz um Proxy diante do objeto RealImage e o aciona assim que
20m necessário.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
O programa em execução public class ProxyPatternDemo tem um main, ou seja, um

método principal.
Obs.: O ProxyImage no display carrega a Image uma vez no disco e guarda a RealImage.
Chain of Responsibility / Cadeia de Responsabilidade

Como o nome sugere, o padrão da cadeia de responsabilidades cria uma cadeia de obje-
tos receptores para uma solicitação. Esse padrão desacopla o remetente e o destinatário de
uma solicitação com base no tipo de solicitação. É um padrão comportamental.
Nesse padrão, normalmente cada receptor contém referência a outro receptor. Se um
objeto não puder tratar a solicitação, ele passará para o próximo receptor e assim por diante.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Diagrama – Programa ChainPatternDemo
No AbstractLogger, tem-se algumas constantes. Na parte inferior do diagrama, há vários

“Logger” diferentes, cada um apreciando um nível do programa.
Obs.: O nextLogger indica a existência de uma cadeia.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Na AbstractLogger, há o INFO, DEBUG e ERROR e a indicação do nível que ela está

associada. No logMessage, verifica-se se o nível atual é menor ou igual ao nível citado ante-
riormente. Caso seja, ele escreverá uma message e, se o próximo Logger não for null, ele
fará uma nextLogger.logMessage.
Obs.: Em cada uma dessas implementações, existirão diferenças.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
Execução do programa: AbstratactLogger getChainofLoggers, uma cadeia de Loggers.

O erroLogger tem uma ligação com o FileLogger e este com o ConsoleLogger. No método
25m principal, há o loggerChain. O logMessage expressa qual é o nível e a informação.
A base possui uma cadeia na qual se cria algo e passa-se para a próxima, ou seja, uma
cadeia de responsabilidade.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns IV
DIRETO DO CONCURSO
1. (CESPE/2018/CGM DE JOÃO PESSOA/PB/AUDITOR MUNICIPAL DE CONTROLE

INTERNO/DESENVOLVIMENTO DE SISTEMAS) Acerca de padrões de projeto, JSE e
JME, julgue o item a seguir.
Considere que determinado sistema tenha apresentado problemas de uso excessivo
de recursos de armazenamento na criação de múltiplas instâncias de objetos. Nesse
caso, o padrão Adapter é mais apropriado que o padrão Flyweight para se resolver
o problema.
COMENTÁRIO
O Adapter não se relaciona com a questão da quantidade de múltiplos objetos, mas o

padrão Flyweight, sim.
GABARITO
1. E
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
DESIGN PATTERNS V
COMANDO / COMMAND
O padrão de comando é um padrão de design controlado por dados e se enquadra na

categoria de padrão comportamental.
Uma solicitação é agrupada sob um objeto como comando e passada para o objeto
Invoker. O objeto Invoker procura o objeto apropriado que pode tratar esse comando e passa
o comando para o objeto correspondente, executando-o.
Diagrama – Programa CommandPatternDemo
À esquerda do CommandPatternDemo, há o sistema de ações. Esse sistema liga-se ao

Broker, que compra ou vende ações. Dessa forma, ele pode receber uma ordem ou implan-
tá-la. O Broker usa a interface Order, implementando o BuyStock e o SellStock.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
É perceptível no programa que o Execute é uma ordem que vem da interface Order.
Assim, tanto se pode realizar uma ordem de compra como uma de venda das ações.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
O Broker tem uma lista de ordens (orderList). Então, ele pode aceitar as ordens (takeor-
5m der) e executar as ordens (placeOrders) e, por fim, limpá-las (orderList.clear).
O CommandPatternDemo possui um programa principal para criar o new Stock, uma

nova ordem de compra, de venda, e o Broker. Nesse caso, tem-se um sistema que guarda
uma lista de comandos agrupados no Involker. Ele, em algum momento do futuro código
,poderá executar as ordens uma a uma.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
INTERPRETER / INTÉRPRETE
O padrão do intérprete fornece uma maneira de avaliar a gramática ou expressão da lin-

guagem. Trata-se de um padrão comportamental que envolve a implementação de uma inter-
face de expressão para interpretar um contexto específico. Ele é usado na análise SQL, no
mecanismo de processamento de símbolos etc. Em geral, tem-se algum tipo de expressão
ou conteúdo e o Interpreter o interpreta.
Diagrama – Programa InterpreterPatternDemo
O InterpreterPatternDemo utiliza uma expressão que tem uma TerminalExpression, uma

AndExpression e uma OrExpression.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
A interface Expression com o método interpret recebe um String context, ou seja, o con-
teúdo que vai ser interpretado retornando uma resposta do tipo boolean.
A expressão mais simples no programa é a terminal (TerminalExpression). Pode-se dizer
que ela é uma expressão atômica.
Obs.: O interpret verifica se o contexto tem determinado dado fornecido quando a expres-
são foi criada.
A OrExpression possui duas expressões internas (1 e 2).

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
A AndExpression, assim como a citada anteriormente, tem duas expressões. Nas expres-
sões “&&” e “| |”, ambas precisam ser verdadeiras nas suas operações.
10m
A seguir, apresenta-se o InterpreterPattern em execução:

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
Obs.: Trata-se de um código mais elaborado.
ITERATOR
O padrão Iterator é um padrão de design muito usado nos ambientes de programação

Java e.Net, a fim de se obter uma maneira de acessar os elementos de um objeto de coleção
de maneira sequencial, sem a necessidade de conhecer sua representação subjacente. O
padrão de iterador se enquadra na categoria de padrão comportamental.
Obs.: O iterator mencionado refere-se a um iterator bem comum no código Java.
Diagrama – Programa IteratorPatternDemo

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
Obs.: No Container, é necessário ter o getIterator.
O NameRepository implementa o Container e, em algum momento, ele terá que retornar

o Iterator. Tem-se, nessa parte, a realização de uma classe privada, que não é muito comum,
15m mas é possível.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
Na execução do IteratorPatternDemo, cria-se um repositório de nomes, o qual se inicia

com a busca do Iterator e a sua execução enquanto houver o iter.hasNext.
Obs.: É interessante saber que o Iterator tem um próximo elemento e o busca.
O Iterator, portanto, é uma estratégia, um padrão de design bem simples e comum no

mundo do Java.
MEDIATOR / MEDIADOR
O padrão do mediador é usado para reduzir a complexidade da comunicação entre vários

objetos ou classes. Ele fornece uma classe mediadora que normalmente lida com todas as
comunicações entre diferentes classes e suporta fácil manutenção do código por meio de
baixo acoplamento. O padrão mediador se enquadra na categoria de padrão comportamental.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
Diagrama – Programa MediatorPatternDemo
O chatRoom é bem simples. O sendMessage utiliza o chatRoom, o qual é uma classe

mediadora, porque ela vai estar mais desacoplada.
A seguir, tem-se a execução do programa MediatorPatternDemo:
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
MEMENTO
O padrão Memento é usado para restaurar o estado de um objeto para um estado anterior,
ou seja, memorizar o seu estado. Ele se enquadra na categoria de padrão comportamental.
Diagrama – Programa MementoPatternDemo
20m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
Há, nessa parte, uma classe concreta chamada Memento que tem um estado e, ao cons-
truí-lo, realiza o getState. Percebe-se que ele não tem o setState, ou seja, ele vai permanecer
enquanto a classe existir.
O método Caretaker tem uma lista de mementos, podendo adicionar um Memento state
ou recuperá-lo por meio de int index. A seguir, tem-se o programa MementoPatternDemo
em execução:

Obs.: O Memento não é um Pattern muito utilizado.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns V
DIRETO DO CONCURSO
1. (2015/CESPE/STJ/TÉCNICO JUDICIÁRIO/TECNOLOGIA DA INFORMAÇÃO)

Julgue o próximo item, relativo a design patterns, ECM (Enterprise Content Manage-
ment) e gerenciamento de processos de negócio (BPM).
O padrão de projeto mediator visa a padronizar a gramática e a interpretação de uma
linguagem, ao passo que o padrão iterator verifica como os objetos padronizados inte-
ragem entre si.
COMENTÁRIO
Interpretação remete ao Pattern Interprete. “O padrão do intérprete fornece uma maneira

de avaliar a gramática ou expressão da linguagem”. Já o “padrão que fornece uma classe
mediadora que normalmente lida com todas as comunicações entre diferentes classes e
suporta fácil manutenção do código por meio de baixo acoplamento” é o Mediator.
GABARITO
1. E
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
DESIGN PATTERNS VI
OBSERVADOR / OBSERVER
O padrão observador é usado quando há um relacionamento do tipo um-para-muitos e,

quando um objeto for modificado, seus objetos dependentes devem ser notificados automa-
ticamente. Ele se enquadra na categoria padrão comportamental.
Obs.: Pode-se se dizer que esse design é próximo do Public-Subcribe
Diagrama – Programa ObserverPatternDemo
Os dois pontos principais são o Observer e o Subject.. Apresenta-se, a seguir, como

essas classes estão definidas:
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
Nesse assunto (subject), a cada vez que o estado é alterado, todos os observadores são
notificados (notifyAllObservers). O subject tem a opção de atachar/anexar um novo observa-
dor. Logo, ele se vale da sua lista de observadores e adiciona um novo observador.
Em síntese, toda vez que o subject sofrer um setState, ele é alterado. Assim, é chamada
a função de notificação, que percorre a lista de observadores, solicitando o método update
de cada um deles.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
A classe abstrata tem um subject e um update. Nesse exemplo, na implementação dos

observadores, há o BinaryObserver. Na construção desse observador binário, ele é forçado
5m a receber um subject.
Todos os observadores apresentados (BinaryObserver, OctalObserver e HexaObserver)

estendem a classe Observer. Dessa forma, os três vão funcionar de maneira bem seme-
lhante, ou seja, recebem um subject, se atacham e implementam o método update. A dife-
rença é que, enquanto um converte o estado para uma String binária, o outro transforma para
octal e o terceiro para hexadecimal.
A seguir, observa-se o programa ObserverPatterDemo em execução:
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
O padrão Observer, como sugere o nome, é utilizado com observadores. Tem-se um

assunto com um estado e uma lista de observadores. Toda vez que o estado muda, os obser-
vadores são notificados.
ESTADO / STATE
No padrão State, o comportamento de uma classe muda com base em seu estado. Ele é
classificado como padrão de comportamento.
Nesse padrão, criam-se objetos que representam vários estados e um objeto de contexto
cujo comportamento varia conforme o objeto de estado muda.
Diagrama – Programa StatePatternDemo

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
10m Obs.: Tanto StartState como StopState implementam State.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
Obs.: Esse é um exemplo para mostrar para que serve o State. Ele não é muito cobrado
em questões, mas é importante conhecer os design Patterns, saber como se classi-
ficam e como funcionam. Inclusive, a classificação dos padrões Patterns é bastante
cobrada em provas.
OBJETO NULO / NULL OBJECT
No padrão Objeto Nulo, um objeto nulo substitui a verificação da instância do objeto

NULL. No lugar de colocar uma verificação “if” para um valor nulo, o Objeto Nulo reflete um
relacionamento que não faz nada. Esse objeto nulo também pode ser usado para fornecer
um comportamento padrão caso os dados não estejam disponíveis. Nesse padrão, cria-se
uma classe abstrata, especificando várias operações a serem executadas, classes concretas
estendendo essa classe e uma classe de objeto nula, a qual não implementa nada e será
usada para verificar o valor nulo. Com isso, no lugar de se ter o Null, haverá uma classe con-
creta nula.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
Diagrama – Programa NullPatternDemo
Obs.: Percebe-se que isNil retorna false porque ele não é nulo.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
Uma opção possível no sistema: no lugar de retornar Null, volta-se uma classe concreta
que é Null.
15m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
Diante do exemplo apresentado, é possível dizer que essa forma evita que o usuário rea-
lize muitas verificações do tipo “if’ Not Null”, pois há a garantia de que o objeto nunca será
nulo. Quando ele for nulo, haverá o método isNil=”true”.
STRATEGY/ ESTRATÉGIA
No padrão de estratégia, um comportamento de classe ou seu algoritmo pode ser alte-

rado em tempo de execução. Ele é classificado como um padrão de comportamento. No
padrão Estratégia, criam-se objetos que representam várias estratégias e um objeto de con-
texto cujo comportamento varia conforme seu objeto de estratégia. O objeto de estratégia
altera o algoritmo de execução do objeto de contexto.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
Obs.: Esse é um padrão muito solicitado em questões de concurso. Apesar de ser mais
complexo, é bem popular.
Diagrama – Programa StrategyPatternDemo
Na interface Estratégia, há várias implementações distintas (adicionar, subtrair e

multiplicar).
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
20m
Tem-se, nesse Pattern, uma classe de contexto que altera a forma executada em tempo
de execução do programa. Assim, é possível criar novos contextos com estratégias diferen-
tes, sendo que cada uma delas possui uma implementação distinta do que será feito.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
DIRETO DO CONCURSO
1. (2019/COVEST/COPSET/UFPE/TÉCNICO DE TECNOLOGIA DA INFORMAÇÃO/SIS-

TEMAS) A programação reativa, abordagem que está em crescente adoção para o
desenvolvimento de aplicações Web e Mobile, tem seu principal conceito centrado em
um padrão de projeto. Assinale a alternativa que identifica esse padrão.
a. Adapter
b. Observer
c. Façade
d. Singleton
e. Builder
COMENTÁRIO
Essa pode ser considerada uma questão difícil, porque envolve conhecimento de atua-
lidades. Para entender a questão, é pertinente retomar o conceito de programação reativa:
A programação reativa é um paradigma de programação orientado em torno dos fluxos de
dados e da propagação da mudança. Isso significa que deve ser possível expressar fluxos de
dados estáticos ou dinâmicos com facilidade nas linguagens de programação usadas, além
de que o modelo de execução subjacente propagará automaticamente as alterações através
do fluxo de dados.
Outro conceito que precisa ser retomado é o de Observador: O padrão observador é
usado quando há um relacionamento do tipo um-para-muitos e, quando um objeto for modi-
ficado, seus objetos dependentes devem ser notificados automaticamente. Ele se enquadra
na categoria padrão comportamental. Ao retomar os dois conceitos, evidencia-se a relação
25m do Observer com os fluxos de dados e a propagação da mudança.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VI
2. (2018/COMPERVE/UFRN/ANALISTA DE TECNOLOGIA DA INFORMAÇÃO)

Considerando o padrão de projeto Estratégia (Strategy), é correto afirmar que:
a. uma das consequências positivas desse padrão é que ele reduz a quantidade
de classes.
b. as classes participantes desse padrão são cliente (Client) e estratégia (Strategy).
c. o padrão permite a implementação de estratégias usando comandos condicionais.
d. o padrão Strategy permite a definição e o encapsulamento de uma família de
algoritmos.
COMENTÁRIO
a. É complicado afirmar que o padrão Estratégia reduz a quantidade de classes.

b. As classes participantes desse padrão são contexto (Context) e estratégia (Strategy).
c. Não há nenhum tipo de “if” no Strategy.
d. No padrão Estratégia, criam-se objetos que representam várias estratégias e um objeto
de contexto cujo comportamento varia conforme seu objeto de estratégia. O objeto de es-
tratégia altera o algoritmo de execução do objeto de contexto.
GABARITO
1. b
2. d
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
DESIGN PATTERNS VII
MODELO / TEMPLATE
No padrão de Modelo, uma classe abstrata expõe formas definidas/modelos para execu-
tar seus métodos. Suas subclasses podem substituir a implementação do método conforme a
necessidade, mas a chamada deve ser da mesma maneira definida por uma classe abstrata.
Ele terá uma classe abstrata com vários métodos abstratos, mas essa classe terá uma imple-
mentação concreta de um método chamado Modelo, pois ele dará uma garantia de como os
métodos vão ser executados.
Esse padrão está classificado na categoria padrão de comportamento.
Diagrama – Programa TemplatePatternDemo
Há aqui uma classe abstrata chamada Game. Essa classe é um Template. Ela possui
duas implementações concretas (Cricket e Football).
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
O método Play é o modelo, porque ele define qual é a ordem do jogo.

As classes concretas que estendem o Game têm que implementar os métodos
intermediários.
5m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
Pode-se observar que, na classe Cricket, assim como na classe Football, não há um
método Play implementado, pois quem o tem é a classe Game.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
VISITANTE / VISITOR
No padrão Visitor, usa-se uma classe de visitantes que altera o algoritmo de execução de
uma classe de elemento. Dessa maneira, o algoritmo de execução do elemento pode variar
conforme o visitante variar. Ele está na categoria padrão de comportamento. De acordo com
o padrão, o objeto de elemento deve aceitar o objeto visitante para que o mesmo lide com a
operação no objeto de elemento. Pode-se dizer que ele é uma forma de integrar várias clas-
ses distintas, permitindo uma alteração no comportamento interno da classe por uma outra
classe externa.
Diagrama – Programa VisitorPatternDemo
Todas as classes implementam o método accept. É a partir dele que ocorrerá a interação
10m com o visitante (Visitor).
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
Este é um exemplo concreto do Design Pattern Visitante (Visitor). Esse padrão, como
observado, consegue alterar o algoritmo e percorrê-lo.
O próximo Design Pattern apresentado foi criado pelo JEE.
BUSINESS DELEGATE
O Padrão de Business Delegate é usado para dissociar a camada de apresentação e

a de negócios. Ele é basicamente usado para reduzir a funcionalidade de comunicação ou
pesquisa remota ao código da camada de negócios no código da camada de apresentação.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
Obs.: Os padrões utilizados atualmente pelo JEE estão mais próximos de casos de uso
real de desenvolvimento, a exemplo do Business Delegate. Há também o foco em
separar as camadas ou torná-las menos acopladas.
No nível de negócios, temos as seguintes entidades:

• O código da camada Cliente: apresentação pode ser JSP, servlet ou código Java da
interface do usuário;
• Business Delegate: uma única classe de ponto de entrada para entidades clientes for-
15m necerem acesso aos métodos de Serviço de Negócios;
• Serviço LookUp: o objeto de serviço Lookup é responsável por obter a implementação
de negócio relativa e fornecer acesso ao objeto de negócio ao business delegate;
• Serviço de negócio: interface de serviço de negócio. As classes concretas implementam
esses serviços de negócios para fornecer lógica de implementação de negócios real.
Diagrama – Programa BusinessDelegatePatternDemo

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
Há, no exemplo, duas opções de execução da lógica de negócios, via EJB OU JMS.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
Tem-se exposta, neste Pattern, uma execução que favorece o desacoplamento entre a
camada mais próxima da interface e a camada de negócios. Para isso, utiliza-se o Busines-
sDelegate para decidir qual o tipo de serviço que seria executado a depender do parâme-
tro passado.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
DIRETO DO CONCURSO
1. (2012/ MPE/RS//TÉCNICO EM INFORMÁTICA/SISTEMAS) Assinale a alternativa que

apresenta corretamente um padrão de projeto de software comportamental.
a. Proxy
b. Facade
c. Visitor
d. Decorator
e. Composite
COMENTÁRIO
Pode-se considerar esse tipo de questão como desleal, pois não avalia muito o conheci-
mento do candidato. Trata-se de uma questão relativamente difícil, porque o aluno terá que
saber a classificação de cada um dos Design Patterns. Dessa forma, é necessária atenção
para o conteúdo teórico.
A bibliografia dispõe sobre a classificação de cada um dos Design Patterns:
Padrões de Criação Padrões Estruturais Padrões Comportamentais
Abstract Factory Private Class Data Chain of Responsability
Object Pool Adapter Command
Builder Bridge Interpreter
Factory Method Composite Iterator
Prototype Decorator Mediator
Singleton Business Delegate Memento
Flyweight Observer
Proxy State
Façade (ou Facade) Strategy
Template Method
Visitor
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VII
Tendo em vista a questão, é pertinente retomar o conceito de Visitor: “No padrão Visitor,
usa-se uma classe de visitantes que altera o algoritmo de execução de uma classe de
elemento. Dessa maneira, o algoritmo de execução do elemento pode variar conforme o
visitante variar. Esse padrão está na categoria padrão de comportamento”.
2. (2018/FAURGS/BANRISUL/DESENVOLVIMENTO DE SISTEMAS) Bridge, Template,

Method e Singleton podem ser utilizados durante o projeto de software orientado a
objetos, sendo denominações de:
a. padrões de análise (analysis patterns).
b. normas de coesão de classes.
c. padrões de projeto (design patterns).
d. métricas específicas de software orientado a objetos.
e. tipos de acoplamento.
COMENTÁRIO
Essa questão é mais fácil, pois faz referência ao nome da disciplina.
GABARITO
1. c
2. c
ANOTAÇÕES
DESENVOLVIMENTO WEB
Design Patterns VIII
DESIGN PATTERNS VIII
OBJETO DE ACESSO A DADOS / DATA ACCESS OBJECT
• O Padrão de Objeto de Acesso a Dados ou padrão DAO é usado para separar API ou
operações de acesso de dados de baixo nível dos serviços de negócio de alto nível. É
composto por:
➢ Interface de objeto de acesso a dados: essa interface define as operações padrão a

serem executadas nos objetos de modelo.
➢ Classe concreta Data Access Object: essa classe implementa a interface acima. Essa
classe é responsável por obter dados de uma fonte de dados que pode ser bancos de dados,
xml ou qualquer outro mecanismo de armazenamento.
➢ Objeto de modelo ou Objeto de valor: esse objeto é um POJO simples que contém
métodos get/set para armazenar dados recuperados usando a classe DAO.
5m
ANOTAÇÕES
DESENVOLVIMENTO WEB
public class Student {

private String name;
private int rollNo;
Student(String name, int rollNo){
this.name = name;
this.rollNo = rollNo;
}
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
public int getRollNo() {
return rollNo;
}
public void setRollNo(int rollNo) {
this.rollNo = rollNo;
}
import java.util.List;
public interface StudentDao {
public List getAllStudents();
public Student getStudent(int rollNo);
public void updateStudent(Student student);
public void deleteStudent(Student student);
import java.util.ArrayList;
public class StudentDaoImpl implements StudentDao {
//lista funcionando como banco de dados
List students;
public StudentDaoImpl(){
students = new ArrayList();
Student student1 = new Student(“Robert”,0);
ANOTAÇÕES
DESENVOLVIMENTO WEB
Student student2 = new Student(“John”,1); students.add(student1);

students.add(student2);
}
@Override
public void deleteStudent(Student student) {
students.remove(student.getRollNo());
System.out.println(“Estudante: Roll No “ + student.getRollNo() + “,
excluído do banco de dados”);
//recupera lista de estudantes do banco de dados
@Override
public List getAllStudents() {
return students;
}
@Override
public Student getStudent(int rollNo) {
return students.get(rollNo);
}
@Override
public void updateStudent(Student student) {
students.get(student.getRollNo()).setName(student.getName());
System.out.println(“Estudante: Roll No “ + student.getRollNo() + “,
atualizado no banco de dados”);
}
public class DaoPatternDemo {
public static void main(String[] args) {
StudentDao studentDao = new StudentDaoImpl();
//imprime todos estudantes
for (Student student: studentDao.getAllStudents()) {
System.out.println(“Student: [RollNo: “ + student.getRollNo() + “, Name:
“ + student.getName() + “ ]”);
}
//atualiza o estudante
Student student = studentDao.getAllStudents().get(0);
ANOTAÇÕES
DESENVOLVIMENTO WEB
student.setName(“Michael”);
studentDao.updateStudent(student);
//recupera o estudante
studentDao.getStudent(0);
System.out.println(“Student: [RollNo: “ + student.getRollNo() +
“, Name: “ + student.getName() + “ ]”);
}
// Saída
Student: [RollNo: 0, Name: Robert ]
Student: [RollNo: 1, Name: John ]
Student: Roll No 0, atualizado no banco de dados
Student: [RollNo: 0, Name: Michael ]
10m
FRONT CONTROLLER
• O padrão de design Front Controller é usado para fornecer um mecanismo centrali-

zado de tratamento de solicitações, para que todas as solicitações sejam tratadas por
um único manipulador.
• Esse manipulador pode fazer a autenticação/autorização/log ou rastreamento de soli-
citação e depois passar as solicitações para os manipuladores correspondentes. É
formado pelos seguintes componentes.
➢ Front Controller: Manipulador único para todos os tipos de solicitações que chegam ao
aplicativo;
➢ Dispatcher: O Front Controller pode usar um objeto despachante que pode despachar
a solicitação para o manipulador específico correspondente.
➢ View: Views são o objeto para o qual as solicitações são feitas.
ANOTAÇÕES
DESENVOLVIMENTO WEB
public class HomeView {

public void show(){
System.out.println(“Exibindo Home Page”);
}
public class StudentView {
public void show(){
System.out.println(“Exibindo Student Page”);
}
public class Dispatcher {
private StudentView studentView;
private HomeView homeView;
public Dispatcher(){
studentView = new StudentView();
homeView = new HomeView();
}
public void dispatch(String request){
if(request.equalsIgnoreCase(“STUDENT”)){
studentView.show();
}
ANOTAÇÕES
DESENVOLVIMENTO WEB
else{
HomeView.show();
}
15m
public class FrontController {
private Dispatcher dispatcher;
public FrontController(){
dispatcher = new Dispatcher();
}
private boolean isAuthenticUser(){
System.out.println(“Usuário autenticado com sucesso.”);
return true;
}
private void trackRequest(String request){
System.out.println(“Página solicitada: “ + request);
}
public void dispatchRequest(String request){
//loga cada solicitação
rackRequest(request);
//autentica o usuário
if(isAuthenticUser()){
dispatcher.dispatch(request);
}
public class FrontControllerPatternDemo {
FrontController frontController = new FrontController();
frontController.dispatchRequest(“HOME”);
frontController.dispatchRequest(“STUDENT”);
}
// Saída
Página solicitada: HOME
Usuário autenticado com sucesso.
Exibindo Home Page
Página solicitada: STUDENT
ANOTAÇÕES
DESENVOLVIMENTO WEB
Usuário autenticado com sucesso.

Exibindo Student Page
SERVICE LOCATOR
• O padrão de design Service Locator é usado quando queremos localizar vários servi-
ços usando a consulta JNDI.
• Considerando o alto custo de procurar um serviço na JNDI, o padrão Service Locator
utiliza a técnica de cache.
• Na primeira vez em que um serviço é necessário, o Service Locator consulta no JNDI
e armazena em cache o objeto de serviço.
• Outras pesquisas para o mesmo serviço via Service Locator são feitos em seu cache,
o que melhora o desempenho do aplicativo em grande medida.
• Os componentes deste padrão de design são:
➢ Service: Serviço real que processará a solicitação.

➢ Context / Initial Context: O contexto JNDI carrega a referência ao serviço usado para
fins de pesquisa.
➢ Service Locator: É um ponto de contato único para obter serviços pela pesquisa JNDI
que armazena em cache os serviços.
➢ Cache: Cache para armazenar referências de serviços para reutilizá-los.
➢ Client: Client é o objeto que chama os serviços via Service Locator.
20m
DESENVOLVIMENTO WEB
public interface Service {

public String getName();
public void execute();
}
public class Service1 implements Service {
public void execute(){
System.out.println(“Executando Service1”);
}
@Override
return “Service1”;
}
public class Service2 implements Service {
public void execute(){
System.out.println(“Executanto Service2”);
}
@Override
return “Service2”;
}
public class InitialContext {
public Object lookup(String jndiName){
if(jndiName.equalsIgnoreCase(“SERVICE1”)){
System.out.println(“Buscando e criando um novo objeto Service1”);
return new Service1();
}
else if (jndiName.equalsIgnoreCase(“SERVICE2”)){
System.out.println(“ Buscando e criando um novo objeto Service2”);
return new Service2();
}
return null;
import java.util.ArrayList;
ANOTAÇÕES
DESENVOLVIMENTO WEB
public class Cache {

private List services;
public Cache(){
services = new ArrayList();
}
public Service getService(String serviceName){
for (Service service: services) {
if(service.getName().equalsIgnoreCase(serviceName)){
System.out.println(“Retornando objeto cacheado “ + serviceName);
return service;
}
return null;
public void addService(Service newService){
boolean exists = false;
for (Service service: services) {
if(service.getName().equalsIgnoreCase(newService.getName())){
exists = true;
}
if(!exists){
services.add(newService);
}
public class ServiceLocator {
private static Cache cache;
static {
cache = new Cache();
}
public static Service getService(String jndiName){
Service service = cache.getService(jndiName);
if(service!= null){
return service;
}
InitialContext context = new InitialContext(); Service service1 =
(Service)context.lookup(jndiName); cache.addService(service1);
return service1;
DESENVOLVIMENTO WEB
}.
public class ServiceLocatorPatternDemo {
Service service = ServiceLocator.getService(“Service1”);
service.execute();
service = ServiceLocator.getService(“Service2”);
service.execute();
service.execute();
service.execute();
/ Saída
Buscando e criando um novo objeto Service1
Executando Service1
Buscando e criando um novo objeto Service2
Executando Service2
Retornando objeto cacheado Service1
Executando Service1
Retornando objeto cacheado Service2
Executando Service2
DIRETO DO CONCURSO
1. (FCC/TJ–PE/TÉCNICO JUDICIÁRIO/2012) Analise o texto: É um design pattern que
25m
permite que uma aplicação seja desenvolvida de forma que a camada de acesso aos
dados seja isolada das camadas superiores. Numa aplicação que utiliza a arquitetura
MVC, todas as funcionalidades de bancos de dados, tais como estabelecimento de
conexões, mapeamento de objetos Java para tipos de dados SQL ou execução de
comandos SQL, devem ser feitas por classes representadas nesse design pattern.
O texto faz referência ao design pattern

a. Data Business Object.
b. Data Access Object.
c. Data Command Object.
d. Session Façade.
e. Data Transfer Object.
DESENVOLVIMENTO WEB
COMENTÁRIO
•O Padrão de Objeto de Acesso a Dados ou padrão DAO é usado para separar API ou
operações de acesso de dados de baixo nível dos serviços de negócio de alto nível. É
composto por:
➢ Interface de objeto de acesso a dados: essa interface define as operações padrão a
serem executadas nos objetos de modelo;
➢ Classe concreta Data Access Object: essa classe implementa a interface acima. Essa
classe é responsável por obter dados de uma fonte de dados que pode ser bancos de da-
dos, xml ou qualquer outro mecanismo de armazenamento;
Em se tratando de acesso de dados, comandos SQL, o único desing pattern possível é o
Data Access Object.
2. (CESGRANRIO/PETROBRAS/ANALISTA DE SISTEMAS) O Controlador Frontal (Front

Controller) é um dos padrões do catálogo J2EE. Esse padrão propicia ao desenolvedor
que o utiliza na construção de uma aplicação Web, em camadas,
a. organizar a camada de integração.
b. implementar o tratamento de todas as requisições que chegam ao lado servidor da
aplicação, provenientes do cliente.
c. implementar o componente View da tríade MVC (Model-View-Controller).
d. implementar o controle de acesso dentro de cada caso de uso da aplicação Web.
e. expor à camada de negócio as estruturas de dados da camada de apresentação.
ANOTAÇÕES
DESENVOLVIMENTO WEB
COMENTÁRIO
• O padrão de design Front Controller é usado para fornecer um mecanismo centralizado
de tratamento de solicitações, para que todas as solicitações sejam tratadas por um único
manipulador.
• Esse manipulador pode fazer a autenticação/autorização/log ou rastreamento de solici-
tação e depois passar as solicitações para os manipuladores correspondentes. É formado
pelos seguintes componentes:
➢ Front Controller: Manipulador único para todos os tipos de solicitações que chegam ao
aplicativo;
➢ Dispatcher: O Front Controller pode usar um objeto despachante que pode despachar a
solicitação para o manipulador específico correspondente.
GABARITO
1. b
2. b
ANOTAÇÕES
Padrões GRASP
Professor Rogerão Araújo
2
Teoria, prática e questões de
concursos
Professor Rogerão Araújo 3

Introdução e conceituação

Padrões de projetos

Conceituação
• Determinam:
• Nomes
• Motivações
• Expõem soluções voltadas para um problema recorrente em
sistemas orientados a objeto
• Devem ser ilustrados com:
• Exemplos
• Dicas de implementação

Conceituação
• São soluções repetíveis gerais para um problema comum no projeto
de software
• São como modelos pré-fabricados que se pode personalizar para
resolver um problema de projeto recorrente no seu código
• São conceitos gerais para resolver um problema específico
• Não são trechos de código específico
• Pode-se:
• Seguir os detalhes do padrão
• Implementar uma solução que se adapte às realidades do programa

Conceituação
• Podem acelerar o processo de desenvolvimento
• Fornecendo paradigmas de desenvolvimento testados e comprovados
• O projeto eficaz do software requer a consideração de problemas
que podem não se tornar visíveis até mais tarde na implementação
• Reutilização de padrões de projetos
• Ajuda a evitar problemas sutis
• Que podem causar grandes problemas
• Melhora a legibilidade do código
• Para codificadores e arquitetos familiarizados com os padrões

Padrões e algoritmos
São frequentemente confundidos

Ambos os conceitos descrevem soluções típicas para alguns problemas
conhecidos
Algoritmo Padrão
O código do mesmo padrão

Define um conjunto claro de ações É uma descrição de nível mais alto
aplicado a dois programas
que podem atingir algum objetivo de uma solução
diferentes pode ser diferente

Padrões e algoritmos
Algoritmo Padrão
É uma receita culinária É mais como um modelo
Pode-se ver qual é o resultado e seus

Ambos têm etapas claras para alcançar
recursos, mas a ordem exata da
um objetivo
implementação depende do programador

Quatro elementos essenciais
Nome do padrão
Problema Solução Consequências
Descrevem os possíveis prós e

Representa uma descrição detalhada
Representa o problema de que o contras que devem ser considerados
de uma solução proposta para o
padrão trata quando o padrão é implementado e
problema
as consequências do uso do padrão

Benefícios
São um conjunto de ferramentas de soluções testadas e
comprovadas para problemas comuns no projeto de software
Conhecer padrões ainda é útil porque ensina como resolver todos os

tipos de problemas usando princípios de projeto orientado a objetos
Mesmo que se nunca encontre esses problemas

Benefícios
Definem um idioma comum que a equipe de desenvolvimento
podem usar para se comunicar com mais eficiência
Ao se deparar com um problema e citar um padrão para

resolvê-lo
Todos entenderão a ideia por trás Não é necessário explicar o padrão

de sua sugestão se todos conhecerem sua ideia

Questões de concursos
[FUMARC 2023 AL/MG – Analista Legislativo – Analista de Sistemas I –
Desenvolvimento de Sistemas] Os padrões de projeto na Engenharia de
Software representam soluções que podem ser reusadas em diferentes
contextos para determinados problemas que ocorrem com frequência.

Desenvolvimento de Sistemas] Analise as afirmativas abaixo sobre
alguns elementos que descrevem os Padrões de Projeto:
• [I] Problema: descreve o problema de que o padrão trata.
• [II] Solução: fornece uma descrição detalhada de uma solução
proposta para o problema.
• [III] Consequências: descrevem os possíveis prós e contras que devem
ser considerados quando o padrão é implementado e as
consequências do uso do padrão.

Desenvolvimento de Sistemas] Analise as afirmativas abaixo sobre
alguns elementos que descrevem os Padrões de Projeto:
• [I] Problema: descreve o problema de que o padrão trata.
• [II] Solução: fornece uma descrição detalhada de uma solução
proposta para o problema.
• [III] Consequências: descrevem os possíveis prós e contras que
devem ser considerados quando o padrão é implementado e as
consequências do uso do padrão.

Desenvolvimento de Sistemas] Estão CORRETAS as afirmativas:
• [A] I e II, apenas.
• [B] I e III, apenas.
• [C] II e III, apenas.
• [D] I, II e III.

Desenvolvimento de Sistemas] Estão CORRETAS as afirmativas:
• [A] I e II, apenas.
• [B] I e III, apenas.
• [C] II e III, apenas.
• [D] I, II e III.

[IBFC 2021 Prefeitura de São Gonçalo do Amarante/RN – Analista de
Sistema e Tecnólogo de Informação] Sobre Padrões de Projetos (Design
Patterns), analise as afirmativas abaixo e dê valores Verdadeiro (V) ou
Falso (F).
• [ ] Auxiliam somente projetos de arquiteturas mais simples.
• [ ] Facilitam a documentação e manutenção da arquitetura do
software.
• [ ] Definem um vocabulário comum para a discussão de problemas e
soluções de projeto.

Sistema e Tecnólogo de Informação] Sobre Padrões de Projetos (Design
Patterns), analise as afirmativas abaixo e dê valores Verdadeiro (V) ou
Falso (F).
• [F] Auxiliam somente projetos de arquiteturas mais simples.
• [V] Facilitam a documentação e manutenção da arquitetura do
software.
• [V] Definem um vocabulário comum para a discussão de problemas e
soluções de projeto.

Sistema e Tecnólogo de Informação] Assinale a alternativa que
apresenta a sequência correta de cima para baixo.
• [A] F, V, V
• [B] V, V, F
• [C] F, F, V
• [D] V, F, F

Sistema e Tecnólogo de Informação] Assinale a alternativa que
apresenta a sequência correta de cima para baixo.
• [A] F, V, V
• [B] V, V, F
• [C] F, F, V
• [D] V, F, F

[IBFC 2019 FSA/SP] Sobre as definições de Design Patterns (Padrões de
Desenvolvimento de Software) e suas principais aplicações, analise as
afirmativas abaixo e assinale a alternativa correta.
• [I] São soluções generalistas para problemas recorrentes durante o
desenvolvimento de um software.
• [II] Trata de um framework ou um código pronto.
• [III] É uma definição de alto nível de como um problema comum pode
ser solucionado.

[IBFC 2019 FSA/SP] Sobre as definições de Design Patterns (Padrões de
Desenvolvimento de Software) e suas principais aplicações, analise as
afirmativas abaixo e assinale a alternativa correta.
• [I] São soluções generalistas para problemas recorrentes durante o
desenvolvimento de um software.
• [II] Não Trata de um framework ou um código pronto.
• [III] É uma definição de alto nível de como um problema comum
pode ser solucionado.

[IBFC 2019 FSA/SP]
• [A] Apenas a afirmativa II está correta
• [B] Apenas a afirmativa I está correta
• [C] Apenas as afirmativas I e III estão corretas
• [D] Apenas as afirmativas I e II estão corretas

[IBFC 2019 FSA/SP]
• [A] Apenas a afirmativa II está correta
• [B] Apenas a afirmativa I está correta
• [C] Apenas as afirmativas I e III estão corretas
• [D] Apenas as afirmativas I e II estão corretas

[CESPE 2019 SLU/DF – Analista de Gestão de Resíduos Sólidos –
Informática] Julgue o próximo item, a respeito de domain-driven
design, design patterns, emergent design, enterprise content
management e REST.
• O uso de design patterns leva à unificação dos códigos utilizados em
diferentes aplicações que utilizem o mesmo padrão.

[CESPE 2019 SLU/DF – Analista de Gestão de Resíduos Sólidos –
Informática] Julgue o próximo item, a respeito de domain-driven
design, design patterns, emergent design, enterprise content
management e REST.
• O uso de design patterns leva à unificação dos códigos utilizados em
diferentes aplicações que utilizem o mesmo padrão.
• Gabarito: ERRADO.
• Não necessariamente

[IBFC 2018 Prefeitura de Divinópolis/MG – Analista de Sistemas] Os padrões
de projetos (Design Patterns) são compostos basicamente por 4 elementos
essenciais que são:
• [A] Nome do software + Problema a ser resolvido + Solução dada pelo
padrão + Tempo de desenvolvimento
• [B] Nome do padrão + Problema a ser resolvido + Solução dada pelo
padrão + Consequências
• [C] Nome do software + Problema a ser resolvido + Planejamento das
atividades + Consequências
• [D] Nome do padrão + Problema a ser resolvido + Planejamento das
atividades + Tempo de desenvolvimento

[IBFC 2018 Prefeitura de Divinópolis/MG – Analista de Sistemas] Os padrões
de projetos (Design Patterns) são compostos basicamente por 4 elementos
essenciais que são:
• [A] Nome do software + Problema a ser resolvido + S Solução dada pelo
padrão + Tempo de desenvolvimento
• [B] Nome do padrão + Problema a ser resolvido + Solução dada pelo
padrão + Consequências
• [C] Nome do software + Problema a ser resolvido + Planejamento das
atividades + Consequências
• [D] Nome do padrão + Problema a ser resolvido + Planejamento das
atividades + Tempo de desenvolvimento

[CONSULPLAN 2017 TRE/RJ – Analista Judiciário – Análise de Sistemas]
Um padrão de projeto nomeia, identifica e abstrai 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. Um padrão, em geral,
possui quatro elementos essenciais; assinale-os.
• [A] Solução; aplicação; abstração; e, reutilização.
• [B] Problema; elementos; abstração; e, consequências.
• [C] Consequências; aplicação; reutilização; e, problema.
• [D] Nome do padrão; problema; solução; e, consequências.
31
[CONSULPLAN 2017 TRE/RJ – Analista Judiciário – Análise de Sistemas]
Um padrão de projeto nomeia, identifica e abstrai 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. Um padrão, em geral,
possui quatro elementos essenciais; assinale-os.
• [A] Solução; aplicação; abstração; e, reutilização.
• [B] Problema; elementos; abstração; e, consequências.
• [C] Consequências; aplicação; reutilização; e, problema.
• [D] Nome do padrão; problema; solução; e, consequências.
32
[Instituto AOCP 2016 EBSERH – Analista de Tecnologia da Informação –
Processos (CH-UFPA)] Em projetos orientados a objetos (OO) em geral
aplica-se padrões definidos para serem utilizados no desenvolvimento,
como o GRASP, por exemplo.

Processos (CH-UFPA)] Esses padrões ou “patterns”, como são
conhecidos entre os desenvolvedores e projetistas de sistemas, são
definidos pela OO como
• [A] o treinamento da equipe dentro dos padrões acordados com o
cliente.
• [B] a descrição de um problema e sua solução que pode ser aplicado
a novos contextos.

• [C] as especificações de reuso de código para a padronização das
soluções do software.
• [D] a documentação necessária para o entendimento do requisito e
do projeto de software.

• [E] os artefatos necessários para a construção de um software que
favoreça a manutenção.

• [B] a descrição de um problema e sua solução que pode ser aplicado
a novos contextos.

Distribuição de
responsabilidades

Conceituação
Deve ser compreendida como as obrigações que

um objeto possui quando se leva em conta o seu
papel dentro de um determinado contexto
É preciso considerar ainda as prováveis

colaborações entre diferentes objetos

Conceituação
É um conceito fundamental em um projeto orientado a
objetos
Deve ser cuidadosamente Para garantir
A eficiência e a
Planejada Implementada manutenibilidade de
sistemas

Conceituação
É baseada no princípio da separação de preocupações
Cada classe deve ser responsável por uma única

preocupação ou tarefa específica
O que torna mais fácil entender e manter o sistema ao

longo do tempo
Responsibility-Driven Design (RDD)
É uma abordagem de desenvolvimento

de software que se concentra em
Garantir que cada objeto seja

Identificar as responsabilidades de responsável por um
vários objetos em um sistema comportamento ou funcionalidade
específica e exclusiva

Responsibility-Driven Design (RDD)
É baseado no princípio de que

Suas responsabilidades
Os objetos devem ser
devem ser
Claramente Bem
Autônomos Autocontidos
definidas compreendidas

Objetivos do RDD
Criar um sistema composto por

objetos que sejam
Fracamente Altamente
acoplados coesos
Objetivos do RDD
Isso permite uma
maior flexibilidade e
Fazer com que cada objeto
uma manutenção
mais fácil do sistema
Tenha uma interface Já que as alterações

Seja responsável por
clara e bem definida em um objeto podem
uma funcionalidade
com o restante do ser feitas sem afetar
específica
sistema o restante do sistema

RDD e Padrões GRASP
O RDD é uma abordagem mais

ampla do que o GRASP
RDD se concentra em identificar GRASP se concentra
as responsabilidades dos especificamente em padrões de
objetos no contexto do sistema design que ajudam a atribuir
como um todo responsabilidades aos objeto

RDD e Padrões GRASP
No entanto, ambos Podem ser usados
compartilham o objetivo comum em conjunto
Criar sistemas orientados a objetos com Para ajudar a criar sistemas

objetos orientados a objetos
Bem Altamente Fracamente Bem

Robustos
definidos coesos acoplados projetados

Responsabilidade dos objetos
É definida Está
como relacionada
Um contrato ou
obrigação de uma Ao comportamento
classe
As responsabilidades de um projeto
podem ser divididas em
Conhecer Fazer
Responsabilidades conhecer
Saber
São relacionadas com a distribuição das características do sistema entre as
classes
O conhecimento dos dados
Saber a respeito de outros objetos Saber sobre as coisas que pode
privados que o objeto em questão
relacionados derivar ou calcular
encapsula

Responsabilidades fazer
São relacionadas com a distribuição do comportamento
do sistema entre as classes
A execução de ações que A criação de outros objetos

Controlando e coordenando
condizem com o papel dos quais a instância inicial
atividades em outros objetos
desempenhado por tal objeto depende

Conceituação e visão geral dos
Padrões GRASP

Conceituação
General Responsibility Assignment Software Patterns
Fornecem uma
Consistem em diretrizes
abordagem sistemática
Para atribuir responsabilidade a Para a atribuição de
classes e objetos em projeto responsabilidades às classes do
orientado a objetos projeto

Conceituação
Foram criados com o intuito de tornar o código mais
flexível
Facilitando
A manutenção A extensibilidade

Conceituação
São padrões de projeto orientados a objetos
Que ajudam a definir a distribuição de

responsabilidades
Entre as classes em um sistema de software

Conceituação
Têm objetivo de
Melhorar Torná-lo mais
A qualidade do
projeto de Flexível Extensível Fácil de manter
software

Conceituação
Ajudam a criar sistemas orientados a Fornecem uma estrutura sólida para
objetos bem projetados a distribuição de responsabilidades
Com Podem ser aplicados em diversos
Responsabilidades
Baixo acoplamento Projetos Cenários
bem definidas

Classificação
Padrões Fundamentais Padrões Avançados

Information Expert Polymorphism
Creator
Pure Fabrication
High Cohesion
Indirection
Low Coupling
Controller Protected Variations

Padrões Fundamentais
Information Creator High Low Coupling Controller

Expert • Criador Cohesion • Baixo • Controlador
• Especialista na • Alta Coesão Acoplamento
Informação

Padrões
Polymorphism Pure Fabrication Indirection Protected

• Polimorfismo • Fabricação/invenção • Indireção Variations
pura • Proteção contra
variações

[CESPE/CEBRASPE 2022 BANRISUL – Quality Assurance (QA) e Analistas
de Teste] Julgue o item a seguir, a respeito dos padrões GRASP (general
responsibility assignment software patterns).
• Entre os padrões definidos pelo GRASP, destacam-se baixa coesão e
alto acoplamento.

de Teste] Julgue o item a seguir, a respeito dos padrões GRASP (general
responsibility assignment software patterns).
• Entre os padrões definidos pelo GRASP, destacam-se baixa alta
coesão e alto baixo acoplamento.

[IFB 2017 IFB – Professor – Informática – Desenvolvimento de Sistemas]
Existem nove padrões GRASP. Assinale a alternativa em que TODOS os
elementos fazem parte desses padrões:
• [A] Criador, Especialista na Informação, Controlador
• [B] Controlador, Acoplamento Baixo, Encapsulamento
• [C] Polimorfismo, Encapsulamento, Acoplamento Baixo
• [D] Coesão Alta, Especialista na Informação, Cadeia de
Responsabilidade
• [E] Criador, Encapsulamento, Polimorfismo

[IFB 2017 IFB – Professor – Informática – Desenvolvimento de Sistemas]
Existem nove padrões GRASP. Assinale a alternativa em que TODOS os
elementos fazem parte desses padrões:
• [A] Criador, Especialista na Informação, Controlador
• [B] Controlador, Acoplamento Baixo, Encapsulamento
• [C] Polimorfismo, Encapsulamento, Acoplamento Baixo
• [D] Coesão Alta, Especialista na Informação, Cadeia de
Responsabilidade
• [E] Criador, Encapsulamento, Polimorfismo

[UNIMONTES 2017 Prefeitura de Jaíba/MG – Analista de Sistemas] A
partir dos fundamentos da Engenharia de Software e dos padrões
General Responsibility Assignment Software Patterns [or Principles]
(GRASP), assinale a alternativa INCORRETA.
• [A] São exemplos de padrões GRASP: Factory Method, High Cohesion,
Low Coupling, Polymorphism e Pure Fabrication.
• [B] Os padrões GRASP servem para a resolução de problemas comuns
e típicos de desenvolvimento de software. Essas técnicas
documentam e normatizam as práticas já conhecidas, consolidadas e
testadas no mercado.

[UNIMONTES 2017 Prefeitura de Jaíba/MG – Analista de Sistemas] A partir
dos fundamentos da Engenharia de Software e dos padrões General
Responsibility Assignment Software Patterns [or Principles] (GRASP), assinale
a alternativa INCORRETA.
• [C] Os padrões GRASP visam descrever princípios de fundamental
importância para a atribuição de responsabilidades em projetos de
software não orientados a objetos.
• [D] Os padrões GRASP podem ser caracterizados como uma filosofia de
design ou mesmo uma ferramenta mental que são úteis para o
desenvolvimento e o aprendizado de um bom design de software.

[UNIMONTES 2017 Prefeitura de Jaíba/MG – Analista de Sistemas] A partir
dos fundamentos da Engenharia de Software e dos padrões General
Responsibility Assignment Software Patterns [or Principles] (GRASP), assinale
a alternativa INCORRETA.
• [A] São exemplos de padrões GRASP: Factory Method, High Cohesion, Low
Coupling, Polymorphism e Pure Fabrication.
• [C] Os padrões GRASP visam descrever princípios de fundamental
importância para a atribuição de responsabilidades em projetos de
software não orientados a objetos.
• Gabarito: letra C, mas deveria ser ANULADO.

[CESPE 2010 SERPRO – Analista – Desenvolvimento de Sistemas] Julgue
os itens seguintes referentes a padrões de projeto.
• Os padrões GRASP (general responsibility assignment software
patterns) consistem em modelos de distribuição de responsabilidades
a classes e objetos em implementações orientadas a objetos. Os
principais exemplos de padrões GRASP são: Information Expert,
Creator, Visitor, Controller, Iterator, Low Coupling, High Cohesion,
Polymorphism, State, Strategy, Pure Fabrication, Indirection, Proxy e
Protected Variations.

[CESPE 2010 SERPRO – Analista – Desenvolvimento de Sistemas] Julgue
os itens seguintes referentes a padrões de projeto.
• Os padrões GRASP (general responsibility assignment software
patterns) consistem em modelos de distribuição de responsabilidades
a classes e objetos em implementações orientadas a objetos. Os
principais exemplos de padrões GRASP são: Information Expert,
Creator, Visitor, Controller, Iterator, Low Coupling, High Cohesion,
Polymorphism, State, Strategy, Pure Fabrication, Indirection, Proxy e
Protected Variations.

[CESPE 2010 MPU – Analista de Informática – Desenvolvimento de
Sistemas] Um processo de desenvolvimento de software contém a
descrição de uma abordagem para a construção de sofware. A UML
(unified modeling language) é uma linguagem visual para especificar,
documentar e construir os artefatos de sistemas orientados a objetos.

Sistemas] Quanto ao ambiente de desenvolvimento de sistemas
orientados a objetos, julgue o item a seguir.
• GRASP (general responsibility assignment software patterns) consiste
em um conjunto de sete padrões básicos para atribuir
responsabilidades em projeto orientado a objetos: information
expert, creator, controller, low coupling, high cohesion, polymorphism
e pure fabrication.

Comentários
Padrões Fundamentais Padrões Avançados

Information Expert Polymorphism
Creator
Pure Fabrication
High Cohesion
Indirection
Low Coupling
Controller Protected Variations

Sistemas] Quanto ao ambiente de desenvolvimento de sistemas
orientados a objetos, julgue o item a seguir.
• GRASP (general responsibility assignment software patterns) consiste
em um conjunto de sete nove padrões básicos para atribuir
responsabilidades em projeto orientado a objetos: information
expert, creator, controller, low coupling, high cohesion, polymorphism
e, pure fabrication, indirection e protected variations.

Referências

Referências
• GRASP Design Principles. Disponível em:
https://home.cs.colorado.edu/~kena/classes/5448/f12/presentation-
materials/rao.pdf
• GRASP Patterns. Disponível em:
materials/duncan.pdf
• Padrões GRASP. Disponível em:
http://www.ic.uff.br/~leomurta/courses/2008.2/es1/aula13.pdf
• Padrões GRASP – Padrões de Atribuir Responsabilidades. Disponível em:
https://medium.com/@leandrovboas/padr%C3%B5es-grasp-
padr%C3%B5es-de-atribuir-responsabilidades-1ae4351eb204

Padrões GRASP
Professor Rogerão Araújo
2
concursos

Padrões Fundamentais

Visão geral

Padrões
Information Creator High Low Coupling Controller

Expert • Criador Cohesion • Baixo • Controlador
• Especialista na • Alta Coesão Acoplamento
Informação

Padrões
Information Expert Creator High Cohesion
Especialista na
Criador Alta Coesão
Informação
Determina quando devemos
Determina qual classe deve ser Determina que as classes
delegar a responsabilidade para
responsável devem se focar
um outro objeto
Que seja especialista naquele Apenas na sua

Pela criação certos objetos
domínio responsabilidade

Padrões
Low Coupling Controller
Baixo Acoplamento Controlador

Determina que as classes não devem depender Atribui a responsabilidade de lidar com os
de objetos concretos e sim de abstrações eventos do sistema
Para uma classe que representa a um cenário

Para permitir que haja mudanças sem impacto
de caso de uso do sistema global

Information Expert

Conceituação
Especialista na Informação
Determina quando devemos delegar a responsabilidade
para um outro objeto
Que seja especialista naquele domínio

Conceituação
É um princípio utilizado para determinar onde delegar
responsabilidades
Essas responsabilidades incluem
Campos
Métodos Assim em diante
computados
Conceituação
Esse princípio
colocará a
Uma abordagem geral para atribuir responsabilidades é
responsabilidade na
classe
Com a maioria das

Olhar Determinar Determinar informações
necessárias
Para uma A informação

Onde essa informação
determinada necessária para Para cumpri-la
está armazenada
responsabilidade cumpri-la

[CESPE/CEBRASPE 2022 DPE/RO – Analista da Defensoria Pública – Programação] O
GRASP (general responsibility assignment software patterns) define princípios
básicos padrões de projetos orientados a objetos. Considere os seguintes
questionamentos, feitos no âmbito de um sistema escolar onde se conhece a
média total do resultado de um aluno.
• Para se conhecer a média total do resultado de um aluno, qual princípio vai se
direcionar para encontrar a classe de objetos adequada para receber essa
responsabilidade?
• Nesse caso, qual princípio GRASP procura identificar a classe de objetos que tem
a informação necessária para a determinação da média?

[CESPE/CEBRASPE 2022 DPE/RO – Analista da Defensoria Pública –
Programação] Assinale a opção que apresenta o princípio GRASP
presente nos referidos questionamentos.
• [A] especialista na informação (information expert)
• [B] acoplamento baixo (low coupling)
• [C] coesão alta (high cohesion)
• [D] controlador (controller)
• [E] criador (creator)

[CESPE/CEBRASPE 2022 DPE/RO – Analista da Defensoria Pública –
Programação] Assinale a opção que apresenta o princípio GRASP
presente nos referidos questionamentos.
• [A] especialista na informação (information expert)
• [B] acoplamento baixo (low coupling)
• [C] coesão alta (high cohesion)
• [D] controlador (controller)
• [E] criador (creator)

[CESPE/CEBRASPE 2022 BANRISUL – Desenvolvimento de Sistemas]
Acerca dos padrões de projeto em arquitetura de software, julgue o
próximo item.
• O padrão GRASP de Expert é utilizado para atribuir uma
responsabilidade à classe que possui a informação necessária para
atender essa mesma responsabilidade.

próximo item.
• O padrão GRASP de Expert é utilizado para atribuir uma
responsabilidade à classe que possui a informação necessária para
atender essa mesma responsabilidade.
• Gabarito: CERTO.

[CESPE/CEBRASPE 2021 SERPRO – Analista – Especialização:
Desenvolvimento de Sistemas] Considerando o padrão GRASP, julgue o
item a seguir.
• Atribuir responsabilidades para abstrações, e não para objetos, faz
parte do padrão Expert.

item a seguir.
• Atribuir responsabilidades para abstrações, e não para objetos,
objetos faz parte do padrão Information Expert.

[CESPE 2014 TJ/CE – Analista Judiciário – Ciências Computação] Com
relação aos padrões GRASP, assinale a opção correta. (Marque CERTO
ou ERRADO o texto de letra)
• [E] O especialista na informação (information expert) associa-se ao
mapeamento de responsabilidade em que se procura atribuir
responsabilidade à classe que tenha informação necessária para
satisfazê-la.

• [E] O especialista na informação (information expert) associa-se ao
mapeamento de responsabilidade em que se procura atribuir
responsabilidade à classe que tenha informação necessária para
satisfazê-la.

[CESPE 2013 TCE/RO – Analista de Informática] Acerca dos padrões
GRASP, julgue os itens a seguir.
• O padrão Indirection é utilizado para atribuir responsabilidades à
classe que tiver a informação necessária para satisfazer a
responsabilidade.

• O padrão Indirection Information Expert é utilizado para atribuir
responsabilidades à classe que tiver a informação necessária para
satisfazer a responsabilidade.

[CESPE 2013 ANCINE – Analista Administrativo – Área 2] A respeito de
arquitetura e engenharia de software, julgue o item seguinte.
• No design, o padrão GRASP controller visa definir as interações entre
objetos e atribuir responsabilidades às classes.

[CESPE 2013 ANCINE – Analista Administrativo – Área 2] A respeito de
arquitetura e engenharia de software, julgue o item seguinte.
• No design, o padrão GRASP controller Information Expert visa definir
as interações entre objetos e atribuir responsabilidades às classes.

Creator

Conceituação
Criador
Determina qual classe deve ser responsável
Pela criação certos objetos

Conceituação
Descobrir qual classe

Criação de objetos é responsável por
criar objetos
É uma propriedade
É uma das mais comuns
fundamental da relação
atividades em um sistema
entre objetos de classes
orientado a objetos
particulares
[CESPE 2021 SEFAZ/CE – Cargo 4] Com relação à arquitetura de
desenvolvimento de software, julgue os itens a seguir.
• Aplicando-se o padrão de projetos especialista da informação da
abordagem GRASP no desenvolvimento de software orientado a
objetos, ficará claramente definida de quem é a responsabilidade
pela criação de nova instância de uma classe.

[CESPE 2021 SEFAZ/CE – Cargo 4] Com relação à arquitetura de
desenvolvimento de software, julgue os itens a seguir.
• Aplicando-se o padrão de projetos especialista da informação criador
da abordagem GRASP no desenvolvimento de software orientado a
objetos, ficará claramente definida de quem é a responsabilidade
pela criação de nova instância de uma classe.

• [B] O controlador (controller) permite solucionar problemas no
controle de criação de instâncias de classes. Nesse sentido, se a classe
X contiver dados iniciais da classe Y ou se X usar de maneira muito
próxima Y, caberá a X criar instâncias de Y, em que o controller
representaria o padrão mais indicado para solucionar esse problema.

• [B] O controlador (controller) creator permite solucionar problemas
no controle de criação de instâncias de classes. Nesse sentido, se a
classe X contiver dados iniciais da classe Y ou se X usar de maneira
muito próxima Y, caberá a X criar instâncias de Y, em que o controller
creator representaria o padrão mais indicado para solucionar esse
problema.

• [D] O criador (creator) é utilizado para a solução do problema de
quem cria a instância de uma classe com objetos do modelo de
domínio. Nesse caso, se A registra B, então atribui-se à classe B a
responsabilidade de se criar uma instância de A.

• [D] O criador (creator) é utilizado para a solução do problema de
quem cria a instância de uma classe com objetos do modelo de
domínio. Nesse caso, se A registra B, então atribui-se à classe B A a
responsabilidade de se criar uma instância de A B.

• O padrão Pure Fabrication objetiva designar a responsabilidade
unívoca pela criação de uma nova instância de uma classe.

• O padrão Pure Fabrication Creator objetiva designar a
responsabilidade unívoca pela criação de uma nova instância de uma
classe.

High Cohesion

Conceituação
Alta Coesão
Determina que as classes devem se focar
Apenas na sua responsabilidade

Low Coupling

Conceituação
Baixo Acoplamento
Determina que as classes não devem depender de
objetos concretos e sim de abstrações
Para permitir que haja mudanças sem impacto

[CESPE 2018 BNB – Especialista Técnico – Analista de Sistema]
Considerando os conceitos de análise e projeto orientados a objetos,
julgue o item subsecutivo.
• De acordo com os padrões GRASP, a função do low coupling é garantir
que o acoplamento entre classes ou entidades permaneça fraco, de
forma a permitir a maior reutilização possível.

[CESPE 2018 BNB – Especialista Técnico – Analista de Sistema]
Considerando os conceitos de análise e projeto orientados a objetos,
julgue o item subsecutivo.
• De acordo com os padrões GRASP, a função do low coupling é garantir
que o acoplamento entre classes ou entidades permaneça fraco, de
forma a permitir a maior reutilização possível.

[CESPE 2017 SEDF – Analista de Gestão Educacional – Tecnologia da
Informação] Julgue o item a seguir, a respeito de padrões de projetos.
• No padrão GRASP, a alta coesão (high cohesion) serve para mensurar
quão fortemente uma classe está conectada a outras classes.

[CESPE 2017 SEDF – Analista de Gestão Educacional – Tecnologia da
Informação] Julgue o item a seguir, a respeito de padrões de projetos.
• No padrão GRASP, a alta coesão (high cohesion) baixo acoplamento
(low coupling) serve para mensurar quão fortemente uma classe está
conectada a outras classes.

• [C] A alta coesão (high cohesion) é um padrão utilizado para
aprimorar a ligação entre as classes, permitindo que a classe A não
dependa de outras classes. Esse padrão é considerado o princípio
central e útil em projetos orientados a objetos que utilizam GRASP.

• [C] A alta coesão (high cohesion) low coupling é um padrão utilizado
para aprimorar a ligação entre as classes, permitindo que a classe A
não dependa de outras classes. Esse padrão é considerado o princípio
central e útil em projetos orientados a objetos que utilizam GRASP.

[CESPE 2013 SUFRAMA – Analista de Sistemas] Com relação a padrões
de projeto e GRASP, julgue o próximo item.
• Em um cenário em que é necessário minimizar dependências e
maximizar o reúso, bem como atribuir uma responsabilidade para
que o acoplamento mantenha-se fraco, o padrão Expert é mais
adequado que o padrão Low Coupling.

• Em um cenário em que é necessário minimizar dependências e
maximizar o reúso, bem como atribuir uma responsabilidade para
que o acoplamento mantenha-se fraco, o padrão Expert é mais
adequado que o padrão Low Coupling.

Coesão e acoplamento

Coesão e acoplamento
São dois critérios úteis para se analisar a qualidade da interface pública de
uma classe
Coesão Acoplamento
A interface pública será considerada coesa se todos

os seus recursos estiverem relacionados ao conceito É o conceito de uma classe depender da outra
que a classe representa
A classe deve ter função específica e única Para funcionar

Objetivo da coesão e acoplamento
Sobre acoplamento,
Deve-se buscar
no modelo de projeto
No entanto, a
É necessário que as
Remoção de colaboração deverá
classes de projeto
Máxima coesão acoplamento ser mantida em um
colaborem umas
desnecessário nível mínimo
com as outras
aceitável

[FUNCAB 2015 Sinesp – Gerente de Projetos em Tecnologia da
Informação] “No modelo de projeto, é necessário que as classes de
projeto colaborem umas com as outras. No entanto, a colaboração
deverá ser mantida em um nível mínimo aceitável.”
52
Informação] Esta definição se refere à característica de uma classe de
projeto bem formada, conhecida como:
• [A] isolamento.
• [B] baixa coesão.
• [C] independência.
• [D] refatoração.
• [E] baixo acoplamento.
53
Informação] Esta definição se refere à característica de uma classe de
projeto bem formada, conhecida como:
• [A] isolamento.
• [B] baixa coesão.
• [C] independência.
• [D] refatoração.
• [E] baixo acoplamento.
54
[FUNCAB 2014 MDA – Analista de Sistemas] Durante o
desenvolvimento de software com decomposição funcional utilizando
modularização, o objetivo do desenvolvedor é usar rotinas com:
• [A] fraco acoplamento e baixa coesão.
• [B] forte acoplamento e baixa coesão.
• [C] moderado acoplamento e sem coesão.
• [D] forte acoplamente e alta coesão.
• [E] fraco acoplamento e alta coesão.
55
[FUNCAB 2014 MDA – Analista de Sistemas] Durante o
desenvolvimento de software com decomposição funcional utilizando
modularização, o objetivo do desenvolvedor é usar rotinas com:
• [A] fraco acoplamento e baixa coesão.
• [B] forte acoplamento e baixa coesão.
• [C] moderado acoplamento e sem coesão.
• [D] forte acoplamente e alta coesão.
• [E] fraco acoplamento e alta coesão.
56
[FCC 2018 DPE/AM – Assistente Técnico de Defensoria – Programador]
O paradigma de programação Orientada a Objetos − OO utiliza, como
um de seus componentes essenciais, a classe. Uma classe, em
conformidade com os melhores padrões da OO, (Marque CERTO ou
ERRADO o texto da letra)
• [A] deve ter alta coesão, que implica em ter um conjunto limitado de
responsabilidades, e baixo acoplamento, que implica em ter baixa
dependência de outros componentes.
57
• [A] deve ter alta coesão, que implica em ter um conjunto limitado de
responsabilidades, e baixo acoplamento, que implica em ter baixa
dependência de outros componentes.
58
• [B] deve ser completa, portanto, quanto mais atributos os métodos
da classe tiver em comum com outros métodos, mais completa ela se
torna.
59
• [B] deve ser completa, portanto, quanto mais atributos os métodos
da classe tiver em comum com outros métodos, mais completa ela se
torna.
• Coesão
• A interface pública será considerada coesa se todos os seus recursos estiverem
relacionados ao conceito que a classe representa
60
• [C] deve manter o número de colaborações com outras classes, por
meio de seus objetos, o mais alto possível para facilitar os testes.
61
• [C] deve manter o número de colaborações com outras classes, por
meio de seus objetos, o mais alto possível para facilitar os testes.
• Deve-se buscar:
• Máxima coesão
• Remoção de acoplamento desnecessário
62
[FAURGS 2018 BANRISUL – Gestão de TI] Uma dada classe VideoClipe de um
software de edição de vídeo contém um conjunto de métodos para editar
videoclipe. Contanto que cada método se concentre somente em atributos
associados a videoclipe, qual característica de projeto orientado a objetos é
mantida?
• [A] Primitivismo.
• [B] Baixo acoplamento.
• [C] Coesão.
• [D] Polimorfismo.
• [E] Herança.
63
[FAURGS 2018 BANRISUL – Gestão de TI] Uma dada classe VideoClipe de um
software de edição de vídeo contém um conjunto de métodos para editar
videoclipe. Contanto que cada método se concentre somente em atributos
associados a videoclipe, qual característica de projeto orientado a objetos é
mantida?
• [A] Primitivismo.
• [B] Baixo acoplamento.
• [C] Coesão.
• [D] Polimorfismo.
• [E] Herança.
64
[FAURGS 2014 TJ/RS – Programador] Como é denominada a
característica de uma classe de projeto que tem um conjunto de
responsabilidades, pequeno e focado e que, de forma resoluta, aplica
atributos e métodos para implementar essas responsabilidades?
• [A] Baixo acoplamento.
• [B] Alto acoplamento.
• [C] Baixa coesão.
• [D] Alta coesão.
• [E] Persistência.
65
[FAURGS 2014 TJ/RS – Programador] Como é denominada a
característica de uma classe de projeto que tem um conjunto de
responsabilidades, pequeno e focado e que, de forma resoluta, aplica
atributos e métodos para implementar essas responsabilidades?
• [A] Baixo acoplamento.
• [B] Alto acoplamento.
• [C] Baixa coesão.
• [D] Alta coesão.
• [E] Persistência.
66
[CS/UFG 2014 CELG/GT/GO – Analista de Gestão – Analista de
Sistemas] Um resultado desejável de projeto de software é
• [A] alto acoplamento e alta coesão.
• [B] alto acoplamento e baixa coesão.
• [C] baixo acoplamento e alta coesão.
• [D] baixo acoplamento e baixa coesão.
• [E] alto acoplamento e moderada coesão.
67
[CS/UFG 2014 CELG/GT/GO – Analista de Gestão – Analista de
Sistemas] Um resultado desejável de projeto de software é
• [A] alto acoplamento e alta coesão.
• [B] alto acoplamento e baixa coesão.
• [C] baixo acoplamento e alta coesão.
• [D] baixo acoplamento e baixa coesão.
• [E] alto acoplamento e moderada coesão.
68
[COMPERVE 2018 UFRN – Analista de Tecnologia da Informação] Em
um sistema de controle acadêmico, as entidades professor, aluno,
instituição e disciplina são identificadas pelo nome e por um
identificador como CPF, CNPJ ou outro código, dependendo do tipo de
entidade.
70
[COMPERVE 2018 UFRN – Analista de Tecnologia da Informação] Todas
essas entidades possuem informação de endereço e, para modelá-las,
as seguintes ideias foram propostas:
• [I] modelar como uma única classe as entidades professor, aluno,
instituição e disciplina, com atributos nome e identificador.
• [II] criar uma entidade para modelar o endereço.
71
[COMPERVE 2018 UFRN – Analista de Tecnologia da Informação] Todas
essas entidades possuem informação de endereço e, para modelá-las,
as seguintes ideias foram propostas:
• [III] criar uma classe vínculo para representar a relação entre uma
pessoa e uma instituição.
• [IV] criar os identificadores CPF, CNPJ e outro código na mesma classe.
72
[COMPERVE 2018 UFRN – Analista de Tecnologia da Informação]
Considerando as boas práticas de modelagem orientada a objetos, as
ideias cuja aplicação resultaria em uma modelagem ruim são
• [A] I e III.
• [B] II e III.
• [C] I e IV.
• [D] II e IV.
73
[COMPERVE 2018 UFRN – Analista de Tecnologia da Informação]
Considerando as boas práticas de modelagem orientada a objetos, as
ideias cuja aplicação resultaria em uma modelagem ruim são
• [A] I e III.
• [B] II e III.
• [C] I e IV.
• [D] II e IV.
74
[CESPE 2017 TRT 7ª Região – Técnico Judiciário – Tecnologia da
Informação] Acerca de orientação a objetos, assinale a opção correta.
(Marque CERTO ou ERRADO o texto da letra)
• [A] Os desenvolvedores de um sistema devem ter como objetivo a
construção de classes com baixa coesão e alto acoplamento.
75
[CESPE 2017 TRT 7ª Região – Técnico Judiciário – Tecnologia da
Informação] Acerca de orientação a objetos, assinale a opção correta.
(Marque CERTO ou ERRADO o texto da letra)
• [A] Os desenvolvedores de um sistema devem ter como objetivo a
construção de classes com baixa coesão e alto acoplamento.
• Deve-se buscar:
• Máxima coesão
• Remoção de acoplamento desnecessário
76
[CESPE 2015 STJ – Analista Judiciário – Análise de Sistemas de
Informação] Julgue o item subsequente, acerca da linguagem de
programação Delphi e da programação orientada a objetos.
• O princípio da responsabilidade única estabelece que uma classe deva
executar apenas uma tarefa; dessa forma, caso uma classe possua
mais uma responsabilidade, deve–se considerar sua decomposição
em duas ou mais classes.
77
[CESPE 2015 STJ – Analista Judiciário – Análise de Sistemas de
Informação] Julgue o item subsequente, acerca da linguagem de
programação Delphi e da programação orientada a objetos.
• O princípio da responsabilidade única estabelece que uma classe deva
executar apenas uma tarefa; dessa forma, caso uma classe possua
mais uma responsabilidade, deve–se considerar sua decomposição
em duas ou mais classes.
78
[CESPE 2013 PF – Cargo 3] No que se refere às linguagens de
programação, julgue o item subsecutivo.
• Coesão e acoplamento são dois critérios úteis para se analisar a
qualidade da interface pública de uma classe. A interface pública será
considerada coesa se todos os seus recursos estiverem relacionados
ao conceito que a classe representa, enquanto, no acoplamento, uma
classe é dependente de outra.
79
[CESPE 2013 PF – Cargo 3] No que se refere às linguagens de
programação, julgue o item subsecutivo.
• Coesão e acoplamento são dois critérios úteis para se analisar a
qualidade da interface pública de uma classe. A interface pública será
considerada coesa se todos os seus recursos estiverem relacionados
ao conceito que a classe representa, enquanto, no acoplamento, uma
classe é dependente de outra.
80
[CESPE 2011 BRB – Cargo 2] A respeito de programação orientada a
objetos, julgues os itens.
• Para que a interface pública de uma classe seja considerada coesa, é
necessário que todos os recursos dessa interface estejam
relacionados ao conceito que a classe representa.
81
[CESPE 2011 BRB – Cargo 2] A respeito de programação orientada a
objetos, julgues os itens.
• Para que a interface pública de uma classe seja considerada coesa, é
necessário que todos os recursos dessa interface estejam
relacionados ao conceito que a classe representa.
82
Controller

Conceituação
Controlador
Atribui a responsabilidade de lidar com os eventos do
sistema
Para uma classe que representa a um cenário de caso

de uso do sistema global
item a seguir.
• Observa-se a utilização do padrão Controller quando uma classe
recebe a responsabilidade de lidar com eventos do sistema.

item a seguir.
• Observa-se a utilização do padrão Controller quando uma classe
recebe a responsabilidade de lidar com eventos do sistema.

[CESPE 2018 CGM de João Pessoa/PB – Auditor Municipal de Controle
Interno – Desenvolvimento de Sistemas] Acerca de padrões de projeto,
JSE e JME, julgue o item a seguir.
• Ao se empregarem duas classes em que uma delas tanto agrega
quanto usa objetos da outra, é mais indicado utilizar o padrão criador
(creator) que o padrão controlador (controller) do GRASP.

[CESPE 2018 CGM de João Pessoa/PB – Auditor Municipal de Controle
Interno – Desenvolvimento de Sistemas] Acerca de padrões de projeto,
JSE e JME, julgue o item a seguir.
• Ao se empregarem duas classes em que uma delas tanto agrega
quanto usa objetos da outra, é mais indicado utilizar o padrão criador
(creator) que o padrão controlador (controller) do GRASP.

• [A] O acoplamento baixo (low coupling) baseia-se na quantidade de
ligações entre as classes e está destinado à atribuição de
responsabilidade ao primeiro objeto além da camada de interface
com o usuário, que é responsável por receber ou tratar uma
mensagem de operação do sistema.

Comentários
• Low coupling
• Baseia-se na quantidade de ligações entre as classes e está destinado à
atribuição de responsabilidade ao primeiro objeto
• Controller
• É responsável por receber ou tratar uma mensagem de operação do sistema

• [A] O acoplamento baixo (low coupling) baseia-se na quantidade de
ligações entre as classes e está destinado à atribuição de
responsabilidade ao primeiro objeto além da camada de interface
com o usuário, que é responsável por receber ou tratar uma
mensagem de operação do sistema.

• Enquanto os padrões GRASP refletem práticas mais pontuais da
aplicação de técnicas orientadas a objetos, os padrões de projeto GoF
(Gang of Four) exploram soluções mais específicas. Dessa forma, não
há, no GRASP, um padrão que ajude a solucionar, por exemplo, a
definição de qual classe deve ser a responsável por lidar com um
evento de determinada interface.
92
• Enquanto os padrões GRASP refletem práticas mais pontuais da
aplicação de técnicas orientadas a objetos, os padrões de projeto GoF
(Gang of Four) exploram soluções mais específicas. Dessa forma, não
há, Há no GRASP, um padrão que ajude a solucionar, por exemplo, a
definição de qual classe deve ser a responsável por lidar com um
evento de determinada interface.
93
[CESPE 2010 INMETRO – Pesquisador – Desenvolvimento de Sistemas]
Assinale a opção correta com referência aos padrões comportamentais
e aos padrões GRASP. (Marque CERTO ou ERRADO o texto da letra)
• [D] O padrão GRASP denominado Controller é um padrão avaliativo
que dita como atribuir responsabilidades a um desenho orientado a
objeto visando obter baixo acoplamento.
94
[CESPE 2010 INMETRO – Pesquisador – Desenvolvimento de Sistemas]
Assinale a opção correta com referência aos padrões comportamentais
e aos padrões GRASP. (Marque CERTO ou ERRADO o texto da letra)
• [D] O padrão GRASP denominado Controller é um padrão avaliativo
que dita como atribuir responsabilidades a um desenho orientado a
objeto visando obter baixo acoplamento.
95
Referências

Referências
• GRASP Design Principles. Disponível em:
materials/rao.pdf
• Padrões GRASP. Disponível em:
http://www.ic.uff.br/~leomurta/courses/2008.2/es1/aula13.pdf
• Padrões GRASP – Padrões de Atribuir Responsabilidades. Disponível
em: https://medium.com/@leandrovboas/padr%C3%B5es-grasp-
padr%C3%B5es-de-atribuir-responsabilidades-1ae4351eb204

POO
Programação Orientada a Objetos
Rogerão Araújo
2
concursos

Princípios SOLID

Conceituação

Conceituação
São um acrônimo
dos cinco primeiros
Foram introduzidos
princípios da
por Michael Visam a construção de sistemas mais
programação
Feathers
orientada a objetos
e design de código
Após observar que

Identificados por
os cinco princípios
Robert C. Martin Flexíveis Robustos
poderiam se Fáceis de manter
por volta do ano
encaixar nesta
2000
palavra
6
Conceituação
Podem ser aplicados a qualquer linguagem de POO
São cinco princípios da programação orientada a objetos
Que facilitam no desenvolvimento de softwares
Tornando-os fáceis de manter e estender

7
5 Princípios
S O L I D
SRP OCP LSP ISP DIP
Single Liskov Interface Dependency

Open-Closed
Responsiblity Substitution Segregation Inversion
Principle
Principle Principle Principle Principle
Principio da Princípio da Princípio da Princípio da

Princípio Aberto-
Responsabilidade Substituição de Segregação da inversão da
Fechado
Única Liskov Interface dependência
8
5 Princípios
S O L I D
Princípio da
Principio da Princípio da Princípio da inversão da
Princípio Aberto- dependência
Responsabilidade Substituição de Segregação da
Fechado
Única Liskov Interface
Deve-se depender
de abstrações
Deve-se ser capaz As classes As interfaces
Uma classe deve
de estender um derivadas devem devem ser
ter um, e somente
comportamento de ser substituíveis refinadas e que
um, motivo para Não de
uma classe, sem por suas classes sejam específicas
mudar implementações
modificá-lo base ao cliente
9
SRP – Single Responsiblity Principle
Princípio da Responsabilidade Única
Classe deve ter apenas uma única Significa que cada classe deve ter
responsabilidade uma única tarefa ou funcionalidade
Ou seja, deve haver apenas uma O que torna o código mais fácil de
razão para que ela seja alterada entender, testar e manter
10
OCP – Open-Closed Principle
Princípio Aberto-Fechado
Significa que as mudanças no
As entidades de software (classes,
comportamento de uma entidade devem
módulos, etc) devem estar abertas para
ser realizadas por meio da adição de
extensão
novas funcionalidades
Em vez de alterar o código existente, o

Mas fechadas para modificação que minimiza o impacto de mudanças no
sistema
11
LSP – Liskov Substitution Principle
Princípio da Substituição de Liskov

Significa que as classes derivadas devem
Uma classe derivada deve ser
seguir as mesmas regras e possuir as
substituível por sua classe base
mesmas propriedades das classes base
Garantindo que o código que depende da

Sem afetar a corretude do programa classe base funcione corretamente
quando uma classe derivada é utilizada
12
ISP – Interface Segregation Principle
Princípio da Segregação de Interfaces

Significa que as classes não devem ser
As interfaces devem ser específicas e
forçadas a implementar métodos que não
granulares
são necessários para sua funcionalidade
Evitando a criação de interfaces “pesadas”

Em vez de gerais e abrangentes
e pouco flexíveis
13
DIP – Dependency Inversion Principle
Princípio da Inversão de Dependência

As dependências devem ser invertidas,
Significa que as dependências devem ser
de modo que as classes de alto nível não
gerenciadas por meio de interfaces
dependam das classes de baixo nível
Reduzindo o acoplamento entre as

Mas sim de abstrações que definam a
classes e tornando o código mais fácil de
interface entre elas
modificar e testar
14
Benefícios
Foca que que o código

Seja Forneça Permaneça
Fácil de se manter, Extensível para

O máximo de
adaptar e se ajustar Testável e de fácil alterações com o O máximo de
tempo possível em
às alterações de entendimento menor esforço reaproveitamento
utilização
escopo necessário
15
Benefícios
Fornece uma maneira Serve como uma base

baseada em sólida para padrões
princípios OO
Sobre a qual padrões de

Para gerenciar a projetos mais complicados
dependência podem ser construídos e
incorporados naturalmente
16
Benefícios
Resultados em códigos
Flexíveis Robustos Reutilizáveis
17
Benefícios
Facilita a manutenção Promove a reutilização
do código de código
Ao criar classes e interfaces bem definidas

Ao seguir os princípios do SOLID, o código
e coesas, é mais fácil reutilizar essas
tende a ser mais modular e organizado
estruturas em diferentes partes do código
O que facilita a sua manutenção e evolução Reduzindo a duplicação de código e

ao longo do tempo aumentando a produtividade
18
Benefícios
Melhora a testabilidade Reduz o acoplamento
do software entre as classes
O uso de classes e interfaces bem Ao utilizar os princípios do SOLID, é

definidas e isoladas torna o código possível reduzir a dependência
mais fácil de testar entre as classes
Permitindo a criação de testes unitários

O que torna o software mais flexível e
mais eficazes e reduzindo a probabilidade
menos propenso a erros
de regressões
19
Benefícios
Aumenta a escalabilidade Facilita a colaboração
do software entre desenvolvedores
Um código organizado e seguindo
Um código mais organizado e modular padrões conhecidos é mais fácil de ser
é mais fácil de escalar entendido e mantido por outros
desenvolvedores
Pois permite a adição de novas

funcionalidades de forma mais fácil e O que facilita a colaboração e o
sem afetar o funcionamento das partes trabalho em equipe
existentes do código
20
[IESES 2017 CREA/SC – Analista de Sistemas] Assinale a alternativa
correta:
[A] SOLID é um acróstico e, cada letra está relacionada a um princípio
para programação e design orientado a objetos de autoria de Robert C.
Martin. O Acrostico é formado pela inicial de Sistema, Objeto, Lógica,
Informação e, Disign.
[B] SOLID é um acróstico e, cada letra está relacionada a um princípio
para programação e design orientado a objetos de autoria de Robert C.
Martin.
21
[IESES 2017 CREA/SC – Analista de Sistemas] Assinale a alternativa
correta:
[A] SOLID é um acróstico e, cada letra está relacionada a um princípio
para programação e design orientado a objetos de autoria de Robert
C. Martin. O Acrostico é formado pela inicial de Sistema, Objeto,
Lógica, Informação e, Disign pelas iniciais de SPR, OCP, LSP, ISP e DIP.
[B] SOLID é um acróstico e, cada letra está relacionada a um princípio
para programação e design orientado a objetos de autoria de Robert
C. Martin.
22
[IESES 2017 CREA/SC – Analista de Sistemas] Assinale a alternativa correta:
[C] SOLID é um acróstico formado pelas iniciais de SPR, OCP, LSP, ISP e DIP. É
um conjunto consistente de princípios para modelagem matemática e
computacional de sólidos tridimensionais. A modelagem sólida distinguese
das áreas relacionadas de modelagem geométrica e computação gráfica por
sua ênfase na fidelidade física.
[D] Em programação Orientada a Objetos É um conjunto consistente de
princípios para modelagem matemática e computacional de sólidos
tridimensionais. A modelagem sólida distingue-se das áreas relacionadas de
modelagem geométrica e computação gráfica por sua ênfase na fidelidade
física.
23
[IESES 2017 CREA/SC – Analista de Sistemas] Assinale a alternativa correta:
[C] SOLID é um acróstico formado pelas iniciais de SPR, OCP, LSP, ISP e DIP.
É um conjunto consistente de princípios para modelagem matemática e
computacional de sólidos tridimensionais. A modelagem sólida distinguese
das áreas relacionadas de modelagem geométrica e computação gráfica por
sua ênfase na fidelidade física.
[D] Em programação Orientada a Objetos É um conjunto consistente de
princípios para modelagem matemática e computacional de sólidos
tridimensionais. A modelagem sólida distingue-se das áreas relacionadas de
modelagem geométrica e computação gráfica por sua ênfase na fidelidade
física.
24
[IESES 2017 CEGÁS – Assistente Técnico – Programador] Há um conjunto de
princípios para programação e design orientado a objetos estabelecido por
Robert C. Martin. Identifique a alternativa que apresenta corretamente a
sigla e seus significados:
[A] SRP-Princípio da Responsabilidade Única; OCPPrincípio Aberto-Fechado;
LSP-Princípio da Substituição de Liskov; ISP-Princípio da inversão da
dependência; DIP-Princípio da Segregação da Interface.
[B] SRP-Principio da Responsabilidade Única; OCPPrincípio da Substituição de
Liskov; LSP-Princípio Aberto-Fechado; ISP-Princípio da Segregação da
Interface; DIP-Princípio da Independência de Processos.
25
[A] SRP-Princípio da Responsabilidade Única; OCPPrincípio Aberto-
Fechado; LSP-Princípio da Substituição de Liskov; ISP-Princípio da inversão
da dependência; DIP-Princípio da Segregação da Interface.
[B] SRP-Princípio da Responsabilidade Única; OCPPrincípio da Substituição
de Liskov; LSP-Princípio Aberto-Fechado; ISP-Princípio da Segregação da
Interface; DIP-Princípio da Independência de Processos.
26
[C] SRP-Princípio da Responsabilidade Única; OCPPrincípio Aberto-Fechado;
LSP-Princípio da Substituição de Liskov; ISP-Princípio da Segregação da
Interface; DIP-Princípio da inversão da dependência.
[D] SRP-Princípio da Responsabilidade Única; OCPPrincípio Aberto-Fechado;
LSP-Princípio da Substituição de Liskov; ISP-Princípio da Informação e da
Segregação da Interface; DIP-Princípio da inversão da dependência.
27
[C] SRP-Princípio da Responsabilidade Única; OCPPrincípio Aberto-
Fechado; LSP-Princípio da Substituição de Liskov; ISP-Princípio da
Segregação da Interface; DIP-Princípio da inversão da dependência.
[D] SRP-Princípio da Responsabilidade Única; OCPPrincípio Aberto-
Fechado; LSP-Princípio da Substituição de Liskov; ISP-Princípio da da
Informação e da Segregação da Interface; DIP-Princípio da inversão da
dependência.
28
[IESES 2017 CEGÁS – Assistente Técnico – Programador] Há um
conjunto de princípios para programação e design orientado a objetos
estabelecido por Robert C. Martin. Identifique a alternativa que
apresenta corretamente a sigla e seus significados:
29
[FEPESE 2023 Prefeitura de Balneário Camboriú/SC – Especialista em
Inteligência de Dados] São princípios SOLID válidos:
[1] Princípio de substituição de Liskov.
[2] Princípio de responsabilidade compartilhada.
[3] Princípio de inversão de dependência.
[4] Princípio de agregação da interface.
30
Inteligência de Dados] São princípios SOLID válidos:
[1] Princípio de substituição de Liskov.
[2] Princípio de responsabilidade compartilhada.
[3] Princípio de inversão de dependência.
[4] Princípio de agregação da interface.
31
Inteligência de Dados] Assinale a alternativa que indica todas as
afirmativas corretas.
[A] São corretas apenas as afirmativas 1 e 3.
[B] São corretas apenas as afirmativas 1, 2 e 3.
[C] São corretas apenas as afirmativas 1, 2 e 4.
[D] São corretas apenas as afirmativas 1, 3 e 4.
[E] São corretas as afirmativas 1, 2, 3 e 4.
32
Inteligência de Dados] Assinale a alternativa que indica todas as
afirmativas corretas.
[A] São corretas apenas as afirmativas 1 e 3.
[B] São corretas apenas as afirmativas 1, 2 e 3.
[C] São corretas apenas as afirmativas 1, 2 e 4.
[D] São corretas apenas as afirmativas 1, 3 e 4.
[E] São corretas as afirmativas 1, 2, 3 e 4.
33
[Instituto AOCP 2018 PRODEB – Especialista de TIC – Construção de
Software] Em relação aos padrões de projeto de software e princípios
arquiteturais, em programação orientada a objetos, existe um princípio
denominado de SOLID. Ele, por sua vez, é composto por 05 princípios
de acordo com as suas iniciais, sendo eles:
[A] S (Single responsibility principle) – O (Openclosed principle) – L
(Liskov substitution principle) – I (Interface segregation principle) e D
(Dependency inversion principle).
[B] S (Solid principle) – O (Open principle) – L (Library principle) – I
(Integration principle) – D (Double principle).
34
[A] S (Single responsibility principle) – O (Openclosed principle) – L
(Liskov substitution principle) – I (Interface segregation principle) e D
(Dependency inversion principle).
[B] S (Solid principle) – O (Open principle) – L (Library principle) – I
(Integration principle) – D (Double principle).
35
denominado de SOLID. Ele, por sua vez, é composto por 05 princípios de
acordo com as suas iniciais, sendo eles:
[C] S (Security closed principle) – O (Open extend principle) – L (Liskov
include principle) – I (Interface duplication principle) – D (Duplicate structure
principle).
[D] S (Single closed principle) – O (Open-closed principle) – L (Library
exclusive principle) – I (Integration case principle) – D (Dependency inversion
principle).
36
denominado de SOLID. Ele, por sua vez, é composto por 05 princípios de
acordo com as suas iniciais, sendo eles:
[C] S (Security closed principle) – O (Open extend principle) – L (Liskov
include principle) – I (Interface duplication principle) – D (Duplicate structure
principle).
[D] S (Single closed principle) – O (Open-closed principle) – L (Library
exclusive principle) – I (Integration case principle) – D (Dependency
inversion principle).
37
[E] S (Security basic principle) – O (Open extern principle) – L (Liskov
include principle) – I (Interface duplication principle) – D (Duplicate
segregation principle).
38
de Teste] Julgue o item a seguir, com relação aos conceitos de SOLID.
Os princípios de programação orientada a objetos que correspondem
aos princípios SOLID são: criador (creator), especialista na informação
(information expert), controlador (controller), polimorfismo
(polymorphism), fabricação pura (pure fabrication).
39
de Teste] Julgue o item a seguir, com relação aos conceitos de SOLID.
Os princípios de programação orientada a objetos que correspondem
aos princípios SOLID padrões GRASP são: criador (creator), especialista
na informação (information expert), controlador (controller),
polimorfismo (polymorphism), fabricação pura (pure fabrication).
Gabarito: ERRADO.
40
SRP
Single Responsibility Principle

SRP
Single Responsibility Principle

Conceituação
Princípio da Responsabilidade Única
Classe deve ter apenas uma única Significa que cada classe deve ter uma
responsabilidade única tarefa ou funcionalidade
Ou seja, deve haver apenas uma razão O que torna o código mais fácil de
para que ela seja alterada entender, testar e manter
42
Conceituação
Uma classe deve ter um, e somente um, motivo para mudar
Deve-se evitar a
Uma classe deve
criação de God Class
Possuir apenas uma
Ser especializada responsabilidade dentro do Classe Deus
software
É uma classe que sabe demais ou

A classe deve ter uma única
Em um único assunto faz demais, com mais de uma
tarefa ou ação para executar
responsabilidade
43
Conceituação
Estabelece que uma classe deve ter apenas uma
única responsabilidade
A classe deve ter apenas um motivo para mudar
Cada classe deve ter uma única

Todas as suas operações devem estar
responsabilidade bem definida e
relacionadas a essa responsabilidade
limitada
44
Objetivos
Identificar • Claramente qual é a responsabilidade da classe
Separar • As responsabilidades diferentes em classes

diferentes
Evitar • A criação de classes que sejam muito genéricas ou

que lidem com muitas responsabilidades diferentes
45
[FCC 2017 TRE/PR – Técnico Judiciário – Programação de Sistemas] Os
princípios SOLID reúnem cinco boas práticas para projetos Orientados a
Objetos-OO. O princípio S, que se refere ao Single Responsability
Principle-SRP ou Princípio de Responsabilidade Única, indica que uma
classe deve ter uma e, apenas uma, razão para mudar.
46
[FCC 2017 TRE/PR – Técnico Judiciário – Programação de Sistemas]
Considere a classe Java abaixo.
public class UrnaEleitoral {
public void AdicionarCandidato(String nome, int numero, int partido) { }
public decimal CalcularTotalVotosCandidato() { }
public void CadastrarPartidos() { }
public void CadastrarEleitores() { }
public void CadastrarMesarios() { }
}
47
[FCC 2017 TRE/PR – Técnico Judiciário – Programação de Sistemas] Com
base no princípio SRP e nas boas práticas para projetos OO, é correto
afirmar:
[A] O SRP visa aumentar o acoplamento entre classes e separar
responsabilidades como forma de melhorar o código da aplicação OO
sendo desenvolvida.
[B] A classe UrnaEleitoral tem acoplamento baixo, ou seja, tem um
número pequeno de dependências e, portanto, fica mais sujeita a
mudanças em decorrência de alterações em outras classes.
48
afirmar:
[C] Uma classe com mais de um motivo para mudar possui mais de
uma responsabilidade e apresentando dificuldade de manutenção,
mas, por outro lado, tem maior facilidade de reúso e de coesão.
[D] A classe UrnaEleitoral apresenta uma quebra do SRP, uma vez que
possui responsabilidades que deveriam ser de componentes distintos
do software.
49
afirmar:
[E] Em um projeto com várias classes seguindo o padrão da classe
UrnaEleitoral fica mais fácil manter a coesão em um nível mais alto ou
em nível de componentes, pois o software fica com uma divisão clara
de camadas.
50
afirmar:
[D] A classe UrnaEleitoral apresenta uma quebra do SRP, uma vez que
possui responsabilidades que deveriam ser de componentes distintos
do software.
51
OCP
Open-Closed Principle

Conceituação
Princípio Aberto-Fechado
Significa que as mudanças no comportamento
As entidades de software (classes, módulos,
de uma entidade devem ser realizadas por meio
etc) devem estar abertas para extensão
da adição de novas funcionalidades
Em vez de alterar o código existente, o que

Mas fechadas para modificação
minimiza o impacto de mudanças no sistema
53
Conceituação
Quando novos
Objetos ou entidades devem comportamentos e recursos
estar abertos para extensão precisam ser adicionados no
software
Mas fechados para Devemos estender e não

modificação alterar o código fonte original
54
Objetivos
Estruturar o código de forma a permitir a inclusão de novas
funcionalidades sem que haja a necessidade de alterar o código existente
Isso pode ser feito, por exemplo, através do uso de interfaces, classes abstratas
e padrões de design que permitam a adição de novas funcionalidades
Sem afetar o comportamento existente do código
55
Objetivos
Evitar a criação de código duplicado ou espalhado por várias partes do
sistema
Que podem ser difíceis de manter e atualizar
Em vez disso, o código deve ser estruturado de forma a incentivar a
Reutilização Modularidade
56
LSP
Liskov Substitution Principle

Conceituação
Princípio da Substituição de Liskov

Significa que as classes derivadas devem
Uma classe derivada deve ser substituível por
seguir as mesmas regras e possuir as mesmas
sua classe base
propriedades das classes base
Garantindo que o código que depende da

Sem afetar a corretude do programa classe base funcione corretamente quando
uma classe derivada é utilizada
58
Conceituação
Se para cada objeto o1 do tipo S há Se S é um
um objeto o2 do tipo T de forma que subtipo de T
Então os objetos do tipo T,
O comportamento de P é em um programa, podem ser
Para todos os programas P inalterado substituídos pelos objetos de
tipo S
Sem que seja necessário

Quando o1 é substituído por
Definidos em termos de T alterar as propriedades deste
o2 então S é um subtipo de T
programa
59
Objetivos
Garantir que uma classe derivada possa ser usada como uma substituição da
classe base
Sem que isso afete o comportamento correto do programa
Uma classe derivada deve ser substituível pela classe base em todas as
situações em que a classe base é usada
Sem que isso cause erros ou comportamentos inesperados
60
Objetivos
Promover a modularidade e a reutilização de código
Permitindo que as classes derivadas sejam usadas em diferentes partes do

sistema sem afetar o comportamento correto do programa
Isso também facilita a manutenção e a evolução do código ao longo do tempo
61
Exemplo
class A { function imprime (A $objeto) {
public function getNome() { return $objeto->getNome();
echo 'Meu nome é A';
}
}
} // Meu nome é A:
class B extends A { imprimeNome($objeto1);
public function getNome() { // Meu nome é B:
echo 'Meu nome é B'; imprimeNome($objeto2);
}
}
$objeto1 = new A;
$objeto2 = new B;
62
Software] Com base no modelo SOLID utilizado como referência para
padrões de projeto e princípios arquiteturais, um dos seus princípios
denominados de LSP (Liskov substitution principle) diz respeito ao fato
de que
[A] uma classe deve ter apenas uma razão para mudar, sendo coesa.
[B] os objetos devem ser substituíveis com instâncias de seus tipos
base, sem prejudicar o funcionamento do software.
[C] todo o processo de desenvolvimento de software deve ser baseado
em abstrações, já que elas pouco mudam.
64
denominados de LSP (Liskov substitution principle) diz respeito ao fato de
que
[A] uma classe deve ter apenas uma razão para mudar, sendo coesa.
SRP - Princípio da Responsabilidade Única
[B] os objetos devem ser substituíveis com instâncias de seus tipos base,
sem prejudicar o funcionamento do software.
[C] todo o processo de desenvolvimento de software deve ser baseado em
abstrações, já que elas pouco mudam.
DIP - Princípio da Inversão de Dependência
65
de que
[D] deve-se utilizar o conceito de herança o máximo possível,
estendendo para todo e qualquer atributo que possua alguma
semelhança.
[E] os módulos devem ser enxutos tendo poucos comportamentos.
66
de que
[D] deve-se utilizar o conceito de herança o máximo possível,
estendendo para todo e qualquer atributo que possua alguma
semelhança.
OCP - Open-Closed Principle
[E] os módulos devem ser enxutos tendo poucos comportamentos.
67
[IFB 2017 IFB – Professor – Informática] Avalie as afirmativas abaixo
sobre projeto de Software. (Marque CERTO ou ERRADO o texto do
item)
[IV] O princípio da substituição de Liskov sugere que um componente
que usa uma classe base deve funcionar apropriadamente, caso esta
seja substituída por sua superclasse.
68
item)
[IV] O princípio da substituição de Liskov sugere que um componente
que usa uma classe base deve funcionar apropriadamente, caso esta
seja substituída por sua superclasse.
Gabarito: ERRADO.
Uma classe derivada deve ser substituível por sua classe base
Sem afetar a corretude do programa
69
ISP
Interface Segregation Principle

Conceituação
Princípio da Segregação de Interfaces

Significa que as classes não devem ser
As interfaces devem ser específicas e forçadas a implementar métodos que
granulares não são necessários para sua
funcionalidade
Evitando a criação de interfaces

Em vez de gerais e abrangentes “pesadas” e pouco flexíveis
71
Conceituação
Esse princípio
basicamente diz que é
Uma classe
melhor criar interfaces
mais específicas
Não deve ser forçada a

implementar interfaces Ao invés de termos uma
e métodos que não irão única interface genérica
utilizar
72
Objetivos
Promover a coesão e a modularidade do código

Evitando a criação de interfaces excessivamente genéricas ou
complexas
O ISP estabelece que as interfaces de uma classe devem ser
segregadas em interfaces menores e mais específicas
De forma que as classes dependentes
Sem serem forçadas a implementar métodos
possam usar apenas as interfaces que
desnecessários ou irrelevantes
precisam
73
Objetivos
Evitar a criação de dependências desnecessárias entre as classes
Promovendo a reutilização e a modularidade do código
Isso facilita a manutenção e a evolução do código ao longo do tempo
Já que as mudanças em uma interface não afetam as outras partes do

sistema que não são dependentes dela
74
próximo item.
O princípio da segregação de interface dos padrões SOLID define que
uma classe deve possuir somente uma operação para ser executada.
75
próximo item.
O princípio da segregação de interface dos padrões SOLID não define
que uma classe deve possuir somente uma operação para ser
executada.
Gabarito: ERRADO.
76
DIP
Dependency Inversion Principle

Conceituação
Princípio da Inversão de Dependência

As dependências devem ser invertidas, de
Significa que as dependências devem ser
modo que as classes de alto nível não
gerenciadas por meio de interfaces
dependam das classes de baixo nível
Reduzindo o acoplamento entre as classes

Mas sim de abstrações que definam a
e tornando o código mais fácil de
interface entre elas
modificar e testar
78
Conceituação
Dependa de abstrações e não de implementações
Esse princípio pode ser definido da seguinte forma
Módulos de alto nível não devem Abstrações não devem depender de

depender de módulos de baixo nível detalhes
Detalhes devem depender de

Ambos devem depender da abstração
abstrações
79
Objetivos
Promover a modularidade e a reutilização do código
Invertendo a direção das dependências entre as classes
O DIP estabelece que as classes de alto nível não devem depender das classes de baixo
nível,
Mas sim de abstrações
Que podem ser implementadas por diferentes classes de baixo nível
80
Objetivos
Busca promover a flexibilidade e a extensibilidade do código
Permitindo que novas classes de baixo nível possam ser adicionadas

ou substituídas sem afetar as classes de alto nível
Isso facilita a manutenção e a evolução do código ao longo do tempo
Já que as mudanças em uma classe de baixo nível não afetam as

classes de alto nível que dependem dela
81
item)
[V] O princípio da inversão de dependência sugere que um
componente não deve depender de classes concretas mas sim de
abstrações, como Interfaces.
82
item)
[V] O princípio da inversão de dependência sugere que um
componente não deve depender de classes concretas mas sim de
abstrações, como Interfaces.
Gabarito: CERTO.
83
[FUNDEP (Gestão de Concursos) 2022 UFJF – Técnico de Tecnologia da
Informação – Edital nº 70] No contexto dos princípios SOLID, analise as
afirmativas a seguir.
[I] O princípio de inversão de dependência estabelece que uma classe deve
depender de implementações abstratas e não concretas, sempre que
possível.
[II] O princípio aberto / fechado estabelece que uma classe deve estar
fechada para extensões, mas aberta para modificações.
[III] O princípio da responsabilidade única é uma aplicação da propriedade
de coesão, por propor que toda classe deve ter uma única finalidade.
84
Informação – Edital nº 70] No contexto dos princípios SOLID, analise as
afirmativas a seguir.
[I] O princípio de inversão de dependência estabelece que uma classe deve
depender de implementações abstratas e não concretas, sempre que
possível.
[II] O princípio aberto / fechado estabelece que uma classe deve estar
fechada para extensões, mas aberta para modificações.
É o inverso
[III] O princípio da responsabilidade única é uma aplicação da propriedade
de coesão, por propor que toda classe deve ter uma única finalidade.
85
Informação – Edital nº 70] Está(ão) correta(s) a(s) afirmativa(s)
[A] I, apenas.
[B] II, apenas.
[C] III, apenas.
[D] I e III, apenas.
[E] II e III, apenas.
86
Informação – Edital nº 70] Está(ão) correta(s) a(s) afirmativa(s)
[A] I, apenas.
[B] II, apenas.
[C] III, apenas.
[D] I e III, apenas.
[E] II e III, apenas.
87
[CS/UFG 2018 Câmara de Goiânia/GO – Assessor Técnico Legislativo –
Analista de Sistemas] Sejam as classes A e B tais que o relacionamento
entre elas é dado pelo fato de A usar (referenciar) a classe B. Dessa
forma, qual das refatorações a seguir implementa o princípio da
inversão de dependência?
[A] Cria interface para serviços oferecidos por B; a classe A passa a usar
a interface criada; a classe B passa a implementar a interface criada; a
classe A não usa mais a classe B.
[B] Cria interface para serviços oferecidos por A; a classe A passa a
implementar a interface criada; a classe B passa a usar a interface
criada; a classe A não usa mais a classe B.
88
Analista de Sistemas] Sejam as classes A e B tais que o relacionamento entre
elas é dado pelo fato de A usar (referenciar) a classe B. Dessa forma, qual das
refatorações a seguir implementa o princípio da inversão de dependência?
[C] Cria um relacionamento de herança entre as classes A e B (A torna-se
uma especialização de B); métodos da classe B empregados pela classe A são
migrados para a classe A; a classe A não usa mais a classe B.
[D] Cria uma referência para a classe B na classe A; cria um método para
receber uma instância de B (injeção de dependência) e guarda-a na
referência criada; a classe A não usa mais a classe B.
89
Analista de Sistemas] Sejam as classes A e B tais que o relacionamento
entre elas é dado pelo fato de A usar (referenciar) a classe B. Dessa
forma, qual das refatorações a seguir implementa o princípio da
inversão de dependência?
[A] Cria interface para serviços oferecidos por B; a classe A passa a
usar a interface criada; a classe B passa a implementar a interface
criada; a classe A não usa mais a classe B.
90
Referências

Referências
Princípios SOLID: Single Responsability Principle. Disponível em:
https://www.treinaweb.com.br/blog/principios-solid-single-
responsability-principle
O que é SOLID: O guia completo para você entender os 5 princípios da
POO. Disponível em: https://medium.com/desenvolvendo-com-
paixao/o-que-%C3%A9-solid-o-guia-completo-para-voc%C3%AA-
entender-os-5-princ%C3%ADpios-da-poo-2b937b3fc530
The SOLID Principles. Disponível em:
https://corecppil.github.io/Meetups/2020-05-
26_CoreCpp_Worldwide!/The_SOLID_Principles.pdf

DESENVOLVIMENTO WEB
Clean Code
CLEAN CODE
Clean Code (Código limpo)

Programação
Aula 1
Tiago Lage Payne de Pádua
Referências: Clean Code: A handbook of agile software craftsmanship. Robert C. Martin

→ cunhou o termo que dá nome ao código.
Introdução
Obs.: Algumas opiniões do autor podem ir na contramão do pensamento geral, portanto o

candidato deve atentar-se ao fato de a questão solicitar a opinião do autor e respon-
der de acordo, mesmo que seja controverso.
• Existem duas coisas: Programação e Boa Programação;

• Mesmo códigos ruins podem funcionar;
• Se o código não estiver limpo, poderá colocar em risco uma organização; → quando o
código é muito difícil de manter, independente de apresentar bugs, pode tornar extre-
mamente difícil para que um analista dê continuidade ao trabalho iniciado por seu
antecessor, ficando assim em risco a manutenção do conteúdo da organização.
5m
• Todos os anos, inúmeras horas e recursos significativos são perdidos devido a códigos
mal escritos. Mas não precisa ser assim;
• Programação é o que todos tem feito. Agora é a hora de fazer uma boa programação;
→ muitas empresas podem perder muito dinheiro, principalmente no processo de refa-
toração ou de correção de melhoria do código para implementar uma nova funcionali-
dade. → Códigos mal escritos tornam oneroso e trabalhoso a sua melhoria;
• Todos sabem que até o código ruim funciona. Mas são necessários tempo e recursos
para tornar um programa bom;
• Pode ser difícil para outros desenvolvedores descobrir o que está acontecendo em um
código. Mas nunca é tarde para cuidar dos programas; → a refatoração permite corrigir
o código, muitas das vezes, não precisando descartá-lo.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean Code
• O clean code orienta para quais são as melhores práticas e como realmente escre-
ver código;
Características de um Código Limpo
Code Review: processo em que outros analistas fazem a revisão do código escrito por
outro analista. Um código bom gera poucas dúvidas nesse processo, um código ruim gera
diversas dificuldades para os analistas nesse processo de avaliarem sua estrutura.
10m
• Deve ser elegante – o código limpo deve ser agradável de ler; → apesar do termo ser
abstrato, é possível depreender que o autor se refere à organização, nomenclatura de
variáveis e a forma de estruturação do código.
• O código limpo é focado – cada função, cada classe, cada módulo expõe uma atitude
obstinada que permanece inteiramente sem distrações e sem poluir pelos detalhes ao
redor; → as funções são pequenas e cada parte exerce um pequeno papel dentro do
todo que compõe o sistema.
• O código limpo é cuidado – Alguém reservou um tempo para mantê-lo simples e orde-
nado. Foi prestada a devida atenção aos detalhes; → é possível perceber que sistemas
feitos de modo apressados apresentam repetições de códigos, conceitos espalhados,
diversas funções realizando códigos muito semelhantes dentre outros elementos que
demonstrem a falta de organização.
• Executa todos os testes; → é essencial que o código seja testado.
• Não contém duplicação; → analisar trechos de código duplicados, pode ser realizado
por meio de ferramentas como o sonar, que analisa blocos de códigos e sugere uma
possível alteração.
• Minimiza o número de entidades, como classes, métodos, funções e similares; → um
projeto com muitas classes e funções, geralmente, é considerado mal feito, pois as
abstrações não foram utilizadas de maneira adequada.
15m
Nomes Significativos
• Use nomes que revelam uma intenção; → esses nomes podem se referir a classes,
métodos, funções e variáveis. Os nomes devem ser significativos e remeter a algo
específico. Mesmo que o código seja executável, dificulta o entendimento da equipe.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean Code
• Escolher nomes bons gasta tempo, mas economiza mais do que gasta; → devem
revelar a sua intenção. Ex.: “classe cliente” em vez de “classe A”.
• O nome de uma variável, função ou classe deve responder a todas as grandes
perguntas;
• Deve dizer por que existe, o que faz e como é usado;
• Se um nome exigir um comentário, ele não revela sua intenção;
Ex.:
int d; // tempo decorrido em dias.
• Devemos escolher um nome que especifique o que está sendo medido e a unidade
dessa medida;
• Um nome melhor seria:
int tempoDecorridoEmDias;
• Classes e objetos devem ter nomes de frase substantivos ou substantivos como

Cliente, PaginaWiki, Conta e ProcessadorDeEndereço;
• Evite palavras como Gerente, Processador, Dados ou Informacoes no nome de uma
classe; → são termos genéricos e geram dúvida sobre de quais processador, dado ou
informação se trata.
20m
• Um nome de classe não deve ser um verbo;
• Os métodos devem ter nomes de frases verbais ou verbais, como efetuarPagamento,
apagarPagina ou salvar;
• Os acessadores, mutadores e predicados devem ser nomeados por seu valor e prefi-
xados com get, set;
• Quando os construtores estiverem sobrecarregados, use métodos estáticos de fábrica
com nomes que descrevam os argumentos. Por exemplo:
Ex.: Complexo ponto = Complexo.deNumeroReal(23.0); geralmente é melhor que Com-

plexo ponto = new Complexo(23.0);
Complexo.deNumeroReal(23.0); → a classe tem um método estático que é um método
fábrica. Esse método fábrica recebe o argumento e a partir dele, retorna um objeto do
tipo ponto.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean Code
new Complexo(23.0); → o valor é passado e ocorre uma sobrecarga.

Autor demonstra preferência, cria métodos estáticos, fabrica o que fazer, sobrecarga de
construtores.
Escolha uma Palavra por Conceito
• Escolha uma palavra para um conceito abstrato e fique com ela;

• Por exemplo, é confuso em diferentes classes ter métodos: obter, recuperar e get; →
atrapalha o entendimento durante a navegação, pois pode ficar confuso.
• Como você se lembra de qual nome de método combina com qual classe?
• Da mesma forma, é confuso ter um controlador, um gerente e um driver na mesma
base de código;
• Qual é a diferença essencial entre um DeviceManager e um Protocol-Controller?
Funções
Tema bastante recorrente nas provas de concurso.
• A primeira regra das funções é que elas devem ser pequenas;

• A segunda regra das funções é que elas devem ser menores que isso;
• Isso implica que os blocos dentro de instruções if, else, while etc. devem ter uma linha
e provavelmente essa linha deve ser uma chamada de função;
O autor aparenta também ser contra a ideia de blocos de código, recomendando que as
funções sejam extraídas para funções separadas.
25m
• Isso não apenas mantém a função pequena mas também agrega valor ao documental,
porque a função chamada dentro do bloco pode ter um nome bem descritivo;
Argumentos de Função
• Uma função não deve ter mais de 3 argumentos;

• Mantenha o número mais baixo possível;
• Quando uma função parece precisar de mais de dois ou três argumentos, é provável
que alguns desses argumentos devam ser agrupados em uma classe própria;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean Code
• Reduzir o número de argumentos criando objetos a partir deles pode parecer trapaça,
mas não é;
• Agora, quando se diz para reduzir o tamanho de uma função, você definitivamente
pensa em como reduzir o try-catch, pois ele já torna seu código muito maior;
• A resposta é criar uma função contendo apenas as instruções try-catchfinally;
• E separe os corpos do bloco try / catch / finally em funções separadas;
1 public void delete (Page page) {

2 try {
3 deletePageAndAllReferences (page);
4}
5 catch (Exception e) {
6 logError(e);
7}
8}
9
10 private void deletePageAndAllReferences (Page page) throws Exception {
11 deletePage(page);
12 registry.deleteReference (page.name);
13 configkeys.deleteKey(page.name.makeKey());
14 }
15
16 private void logError (Exception e) {
17 logger.log(e.getMessage());
18 }
Ex.: Sempre que tiver um try catch, é recomendado criar uma função que terá unicamente
o try catch.
Apagar todas as páginas e referência, passa a página, chama o método delete page que
tem o bloco try catch. Depois será apagada a página, chamando outro método e por fim apa-
gará a chave e o método de log, que foi extraído para haver o mínimo possível de repetição
de código. → o tratamento de erros ficou completamente separado em uma função só que
tornou o método muito mais claro. Segundo o autor, isso tornaria a lógica mais clara.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean Code
• Isso torna a lógica muito clara;

• Os nomes das funções descrevem facilmente o que estamos tentando alcançar;
• O tratamento de erros pode ser ignorado. Isso fornece uma boa separação que facilita
a compreensão e modificação do código;
• O tratamento de erros é uma coisa – a função deve fazer uma coisa. O tratamento de
erros é outra coisa. Se uma função tem a palavra-chave try, então deve ser a primeira
palavra-chave e não deve haver nada após os blocos catch / finally;
DIRETO DO CONCURSO
1. (2016/CESPE/TRE-PI/ANALISTA JUDICIÁRIO/ANÁLISE DE SISTEMAS) Acerca do
Clean Code, assinale a opção correta.
a. A segurança do código é vital, por isso os programadores devem deixar o código o
mais obscuro possível.
b. Se um valor deve ser utilizado em múltiplos locais do código, é imperativo atribuir
esse valor a uma variável ou a uma constante com nome amigável.
c. As classes devem possuir nome amigável oriundo de verbos, escolhidos no infinitivo,
e não no gerúndio.
d. Para customizar o código, deve-se utilizar o mesmo termo para duas diferentes ideias.
e. Os nomes das variáveis devem ser simplificados, de forma a não criar códigos gordos
(fat codes) – por exemplo, o uso de x para o nome de uma variável é mais apropriado
que MediadosAlunosAprovados.
COMENTÁRIO
Obs.: A respostas devem seguir de acordo com a opinião do autor do termo Clean Code.
a) A segurança do código é vital, por isso os programadores devem deixar o código o mais
claro possível.
30m
b) Se um valor deve ser utilizado em múltiplos locais do código, é imperativo atribuir esse
valor a uma variável ou a uma constante com nome amigável.
c) As classes devem possuir nome amigável oriundo de substantivos.
d) Para customizar o código, não se deve utilizar o mesmo termo para duas diferen-
tes ideias.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean Code
e) Os nomes das variáveis devem ser descritivos – por exemplo, o uso de MediadosAlu-
nosAprovados para o nome de uma variável é mais apropriado que x.
2. (2015/CESPE/TRE-MT/ANALISTA JUDICIÁRIO/ANÁLISE DE SISTEMAS) Assinale

a opção que apresenta instruções de elaboração corretas de acordo com a técnica
Clean Code.
a. Os nomes utilizados devem ser pronunciáveis e devem ter sentido conhecido.
b. Os nomes de classes devem ser verbos no infinitivo e os de métodos devem ser
substantivos.
c. Os nomes de funções e de métodos devem ser longos e descritivos.
d. Os parâmetros devem ser aglutinados em funções, e cada função deve ter, no
máximo, três parâmetros.
e. O comando return deve ser evitado, ao passo que continue e break devem ser prio-
rizados, assim como o goto..
COMENTÁRIO
a) Os nomes utilizados devem ser pronunciáveis e devem ter sentido conhecido.
b) Os nomes de métodos devem ser verbos no infinitivo e os de classes devem ser
substantivos.
c) Os nomes de funções e de métodos devem ser descritivos.
d) Cada função deve ter, no máximo, três parâmetros.
e) O comando return deve ser evitado, ao passo que continue e break devem ser prioriza-
dos, diferente do go to.
GABARITO
1. b

2. a
A presente degravação tem como objetivo auxiliar no acompanhamento e na revisão do conte-
údo ministrado na videoaula. Não recomendamos a substituição do estudo em vídeo pela leitura
exclusiva deste material.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean code II
CLEAN CODE II
CLEAN CODE (CÓDIGO LIMPO)
Comentários
• Se você está escrevendo comentários para provar seu argumento, está come-
tendo um erro;
• Idealmente, os comentários não são obrigatórios;
• Se seu código precisar ser comentado, você está fazendo algo errado;
• Nosso código deve explicar tudo;
• As linguagens de programação modernas são muito fluentes, através das quais pode-
mos explicar facilmente nosso ponto; → atualmente não há as limitações de antiga-
mente, o que permite que o nome seja descritivo e autoexplicativo.
• A nomeação correta pode remover a necessidade de comentários;
• Comentarios legais não são considerados aqui (declarações de direitos autorais e
licenças);
Nomear corretamente é vantajoso, pois, ao chamar o método em qualquer ponto, o pró-

prio nome conterá a explicação, dispensando a necessidade de retornar constantemente ao
comentário para entender o que o método faz.
Formatação
• A formatação deve ressaltar coisas de importância, pois é uma forma de comunicação;

5m
• Um código bagunçado é difícil de ler;
• A legibilidade do código é importante em todas as alterações que serão feitas;
Atualmente existem ferramentas que auxiliam na automatização da tarefa de formatação

do código. Ex.: Pritcher → JavaScript. Através de um arquivo formatado no padrão da empresa,
o programa formata o código todo a partir desse padrão. Sem opinião do desenvolvedor.
• Tente escrever uma classe com no máximo 500 linhas. Classes menores são mais
fáceis de entender;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean code II
• Defina um limite de caracteres por linha de código;

• Um bom limite de caracteres em uma linha é 120;
• Tente manter mais próximos conceitos relacionados verticalmente para criar um fluxo
de código;
• Use espaços entre operadores, parâmetros e vírgulas;
Os espaços em branco, na maioria das linguagens de programação não são considera-

dos, salvo linguagens como a python, por exemplo, em que a indentação determina os blocos
de código (não tem blocos abrindo e fechando com chave).
Objetos e Estruturas de Dados
O objeto nasceu da structure do ser, sendo uma forma primitiva do objeto, mas com o
passar do tempo passaram a ter diferenças importantes.
• Este é um tópico complexo e requer muita atenção;

• Primeiro, precisamos esclarecer a diferença entre objeto e estruturas de dados;
• Os objetos ocultam seus dados atrás de abstrações e expõem funções que operam
nesses dados;
• A estrutura de dados expõe seus dados e não possui funções significativas.
Ex.: um objeto “cliente” terá uma série de atributos, como nome. Um método chamado
setnome ou getnome será usado para recuperar ou alterar o nome do cliente.
Ex.: estrutura de dados: pilha com uma lista de dados. É possível empilhar ou desempi-
lhar nessa pilha.
10m
Essas duas coisas são completamente diferentes. Um é apenas sobre o armazenamento

de dados e o outro é como manipular esses dados.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean code II
1 public class Square {

2 public Point topleft;
3 public double side;
4 }
5
6 public class Rectangle {
7 public Point topLeft;
8 public double height;
9 public double width;
10 }
11
12 public class Circle {
13 public Point center;
14 public double radius;
15 }
17 public class Geometry {
18 public final double PI = 3.141592653589793;
19 public double area (Object shape) throws NoSuchShapeException {
20 if (shape instanceof Square) {
21 Square s = (Square) shape;
22 return s.side * s.side;
23 } else if (shape instanceof Rectangle) {
24 Rectangle r = (Rectangle) shape;
25 return r.height r.width;
26 } else if (shape instanceof Circle) {
27 Circle c = (Circle) shape;
28 return PI c. radius c.radius;
29 }
30 throw new NoSuchShapeException();
31 }
32 }
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean code II
Exemplo de código procedural três formas geométricas chamadas: círculo, quadrado e

retângulo.
Classe de geometria que implementa cálculos como área de objetos: Área do quadrado
= lado ao quadrado, círculo = raio ao quadrado multiplicado por pi e área do retângulo = lado
vezes altura.
• Considere, por exemplo, o exemplo de forma processual abaixo:

– A classe Geometry opera nas três classes de formas;
– As classes de forma são estruturas de dados simples, sem nenhum comportamento;
– Todo o comportamento está na classe Geometry;
• Considere o que aconteceria se uma função perimeter() fosse adicionada à Geometry;

– As classes de forma não seriam afetadas;
– Qualquer outra classe que dependesse das formas também não seria afetada;
– Por outro lado, se adicionar uma nova forma, deve-se alterar todas as funções de
Geometry para lidar com ela.
Observe que as duas condições são diametralmente opostas.

Para adicionar um triângulo e tiver perímetro, será necessário acrescentar mais um if e
também um if abaixo em perimeter.
1 public class Square implements shape {

2 private Point topLeft;
3 private double side;
4 public double area ( ) {
5 Retunr side*side;
6 }
7 }
8
9 public class Rectangle implements Shape {
10 private Point topLeft;
11 private double height;
12 private double width;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean code II

14 Return height * width;
15 }
16 }
17
18 Public class Circle implements Shape {
19 private Point center;
20 private double radius;
21 public final double PI = 3.1415926533589793;
23 Return PI * radius * radius;
24 }
25 }
Agora podemos facilmente adicionar novas formas, isto é, estruturas de dados em com-
paração com o caso anterior.
A classe implementa uma interface chamada shape. Código mais orientado ao objeto.
O ponto topleft e o lado são privados, e não públicos, exigindo um método get cept.
É mais fácil adicionar uma forma, pois não há uma classe centralizada como geometry
que precise se toda alterada.
15m
Se tivermos que adicionar a função perimeter() em apenas um Shape, somos forçados a
implementar essa função em todas as classes Shapes, pois a classe Shape é uma interface
que contém as funções area() e perimeter(); → lado negativo.
As estruturas de dados facilitam a adição de novas funções sem alterar as estruturas de
dados existentes.
O código OO (usando objetos) facilita a adição de novas classes sem alterar as funções
existentes.
O analista deve analisar qual será a abordagem mais vantajosa para seu trabalho.
Ex.: sistema de processamento em lote: a partir de uma entrada, realiza um processa-
mento e gera uma saída, contando com uma série de funções. A abordagem orientado ao
objeto não seria a mais útil, sendo a procedural mais adequada para esse tipo de sistema.
O código procedural (usando estruturas de dados) dificulta a adição de novas estruturas
de dados, porque todas as funções devem ser alteradas;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean code II
O código OO dificulta a adição de novas funções, pois todas as classes devem ser
alteradas.
Portanto, as coisas difíceis para OO são fáceis para procedural, e as coisas difíceis para
procedural são fáceis para OO.
Em qualquer sistema complexo, haverá momentos em que queremos adicionar novos tipos
de dados em vez de novas funções. Para esses casos, objetos e OO são mais apropriados.
Por outro lado, também haverá momentos em que desejaremos adicionar novas funções
em oposição aos tipos de dados. Nesse caso, o código procedural e as estruturas de dados
serão mais apropriadas.
Programadores maduros sabem que a ideia de que tudo é um objeto é um mito. Às
vezes, você realmente fazer deseja estruturas de dados simples com os procedimentos ope-
racionais sobre eles. Dessa forma, deve-se pensar cuidadosamente no que implementar,
pensando também na perspectiva futura de que será fácil atualizar.
Considerando o exemplo acima, como qualquer nova forma pode ser adicionada no
futuro, a forma escolhida seria a abordagem OO.
20m
Tratamento de Erros
• O tratamento de erros deve ser planejado com cuidado por todos os programadores;
• Quando coisas erradas acontecem, deve haver um fluxo correto para tratar;
• Deve-se dar preferência ao lançamento de uma exceção do que tratá-la apenas para
ocultar o erro;
• Crie mensagens com informações sobre o erro;
• Mencione o que falhou. Onde foi esse fracasso? Se possível, mencione por que falhou;
• Examine regras de negócios separadas para erros e tratamento de erros;
• Evite retornar um NULL nos métodos, de preferência para retornar um objeto vazio;
• Evite passar NULL para os métodos; isso pode gerar NullPointerExceptions;
DIRETO DO CONCURSO
1. (2015/CESPE/STJ/ANALISTA JUDICIÁRIO/ANÁLISE DE SISTEMAS DE INFORMA-
ÇÃO) Julgue o próximo item, referente a criptografia, clean code e refatoração.
No contexto de clean code, as funções devem ter tamanho reduzido.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean code II
COMENTÁRIO
No contexto de clean code, as funções devem ter tamanho reduzido.
2. (2017/CESPE/TRE-PE/ANALISTA JUDICIÁRIO/ANÁLISE DE SISTEMAS) Acerca do

clean code, assinale a opção correta.
a. Para se evitar a proliferação de funções curtas, recomenda-se o uso de uma função
longa com muitas variáveis globais, cada qual com variáveis locais de pouco uso.
b. O uso de um código que contenha as letras l e O como variáveis é mais recomendado
que o uso de um código cujas variáveis sejam contador e resultado, por exemplo.
c. Os atuais ambientes de programação permitem que um único arquivo de código-fonte
seja desenvolvido em diferentes linguagens, embora o ideal seja que um código-fonte
contenha apenas uma linguagem.
d. A fim de facilitar o entendimento do código pelos desenvolvedores, recomenda-se
utilizar gírias locais para nomear funções, sempre que possível.
e. Na análise léxica, o uso de uma mesma palavra para dois ou mais propósitos facilita a
compilação de código, diminui o código e aumenta a velocidade dos objetos binários
compilados.
25m
COMENTÁRIO
Os atuais ambientes de programação permitem que um único arquivo de código-fonte seja
desenvolvido em diferentes linguagens, embora o ideal seja que um código-fonte contenha
apenas uma linguagem.
3. (2016/CESPE/TCE-SC/AUDITOR FISCAL DE CONTROLE EXTERNO/INFORMÁTI-

CA) A respeito da análise estática de código-fonte em Clean Code e SonarQube, julgue
o item subsecutivo. De acordo com as diretivas do Clean Code, o número de argumen-
tos de uma função não deve ser igual ou superior a três, devido a sua influência no
entendimento da função.
COMENTÁRIO
De acordo com as diretivas do Clean Code, o número de argumentos de uma função não
deve ser igual ou superior a três, devido a sua influência no entendimento da função.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Clean code II
GABARITO
1. C
2. c
3. C
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services
WEB SERVICES
Referências
A referência bibliográfica utilizada nessa aula será W3C – Web Services Architecture.
Link:
https://www.w3ºrg/TR/2004/NOTE-ws-arch-20040211/
Introdução
• Os Web Services fornecem um meio padrão de interoperar entre diferentes aplicativos
de software, executando em uma variedade de plataformas e/ou estruturas.
Obs.: Até antes de se ter o Web Services, existiam meios para interoperar diferentes apli-
cativos, mas eram soluções acopladas à tecnologia, logo tinha-se que programar em
Java, CIC, C++, para que fosse possível a comunicação de duas aplicações distin-
tas. Contudo, surgiu a necessidade de comunicar dois sistemas diferentes, sendo
que cada um estava executando uma linguagem e uma outra tecnologia, foi nessa
necessidade que o Web Services nasceu.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services
• A arquitetura de Web Services é uma arquitetura de interoperabilidade: identifica os

elementos globais da rede global de Web Services necessários para garantir a intero-
perabilidade entre estes Web Services.
Obs.: O web service descreve como será a comunicação de dois serviços distintos.
O que é um Web Service?

5m
• Um Web Service é um sistema de software projetado para oferecer suporte à interação
máquina a máquina através de uma rede;
• Possui uma interface descrita em um formato processável por máquina (especifica-
mente WSDL – Web Service Description Language);
• Outros sistemas interagem com o Web Service da maneira prescrita por sua descrição
usando mensagens SOAP, normalmente transmitidas usando HTTP com uma seriali-
zação XML em conjunto com outros padrões relacionados à Web.
Obs.: A web service anda em paralelo com a web, sendo esta menos estruturada, pois tem
o objetivo dar informação a serem consumidas por humanos.
Agentes e Serviços
• Um Web Service é uma noção abstrata que deve ser implementada por um
agente concreto;
• O agente é o software ou hardware concreto que envia e recebe mensagens, enquanto o
serviço é o recurso caracterizado pelo conjunto abstrato de funcionalidades fornecidas;
• Para ilustrar essa distinção, pode-se implementar um Web Service específico usando
um agente (talvez escrito em uma linguagem de programação) e posteriormente um
agente diferente (talvez escrito em uma linguagem de programação diferente) com a
mesma funcionalidade.
Ex.: Uma abertura de conta foi escrita em uma certa linguagem (papel de agente), depois
transferiu para outro agente mantendo o mesmo protocolo. Nesse caso, o outro lado que está
se comunicando com esse Web Service pouco se importa com qual é a tecnologia de imple-
mentação, importando apenas se o protocolo é o mesmo.
10m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services
• Embora o agente possa ter sido alterado, o Web Service permanece o mesmo.
Solicitantes e Provedores
• O objetivo de um Web Service é fornecer algumas funcionalidades em nome de seu
proprietário – uma pessoa ou organização, como uma empresa ou um indivíduo;
• A entidade provedora é a pessoa ou organização que fornece um agente apropriado
para implementar um serviço específico;
• Uma entidade solicitante é uma pessoa ou organização que deseja fazer uso do Web
Service da entidade prestadora. Ele usará um agente solicitante para trocar mensa-
gens com o agente da entidade prestadora;
• Na maioria dos casos, o agente solicitante é quem inicia a troca de mensagens,
embora nem sempre;
• Para que essa troca de mensagens seja bem-sucedida, a entidade solicitante e a enti-
dade fornecedora devem primeiro concordar com a semântica e a mecânica da
troca de mensagens;
15m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services
Descrição do Serviço
• A mecânica da troca de mensagens está documentada em uma descrição de Web Ser-
vice (WSD);
• O WSD é uma especificação processável por máquina da interface do Web Service,
escrita em WSDL;
• Ele define os formatos de mensagem, tipos de dados, protocolos de transporte e for-
matos de serialização de transporte que devem ser usados entre o agente solicitante
e o agente provedor;
• Ele também especifica um ou mais locais de rede nos quais um agente provedor pode
ser chamado e pode fornecer algumas informações sobre o padrão de troca de men-
sagens esperado;
• Em essência, a descrição do serviço representa um acordo governando a mecânica de
interação com esse serviço;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services
Semântica
• A semântica de um Web Service é a expectativa compartilhada sobre o comporta-
mento do serviço, em particular em resposta às mensagens enviadas a ele;
• É o "contrato" entre a entidade solicitante e a entidade prestadora em relação ao obje-
tivo e às consequências da interação;
• Embora este contrato represente o acordo geral entre a entidade solicitante e a enti-
dade prestadora sobre como e por que seus respectivos agentes irão interagir, ele não
é necessariamente escrito ou negociado explicitamente;
• Pode ser explícita ou implícita, oral ou escrita, processável por máquina ou orientado
a um humano, e pode ser um acordo legal ou um informal (não legal) acordo;
20m
• Enquanto a descrição do serviço representa um contrato que rege a mecânica da
interação com um serviço específico, a semântica representa um contrato que rege o
significado e o objetivo dessa interação.
Obs.: o descritor (descrição do serviço) será regido por máquinas, agora a semântica será
fora das questões técnicas.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services
• A linha divisória entre esses dois não é necessariamente rígida. À medida que são
usadas linguagens semanticamente mais ricas para descrever a mecânica da intera-
ção, mais informações essenciais podem migrar da semântica informal para a descri-
ção do serviço;
• À medida que essa migração ocorre, mais do trabalho necessário para obter uma inte-
ração bem-sucedida pode ser automatizado.
Visão Geral do Envolvimento de um Web Service

• Há muitas maneiras pelas quais uma entidade solicitante pode contratar e usar um
Web Service;
• Em geral, são necessárias as seguintes etapas gerais:
1. As entidades solicitante e prestadora tornam-se conhecidas uma pela outra;
2. As entidades solicitantes e prestadoras concordam de alguma forma na descrição e
semântica do serviço que governará a interação entre o solicitante e os agentes do provedor;
3. A descrição e a semântica do serviço são realizadas pelos agentes solicitantes e
fornecedores;
4. Os agentes do solicitante e do provedor trocam mensagens, executando algumas
tarefas em nome das entidades do solicitante e do provedor;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services
DIRETO DO CONCURSO
1. (CESPE/SLU-DF/ANALISTA DE GESTÃO DE RESÍDUOS SÓLIDOS/INFORMÁTI-
CA/2019) Acerca de arquitetura de software, julgue o item a seguir. Um Web Service
pode assumir o papel de provedor de serviço e de consumidor de serviço.
25m
COMENTÁRIO
Definição formal. Veja:
Solicitantes e Provedores
• O objetivo de um Web Service é fornecer algumas funcionalidades em nome de seu pro-
prietário – uma pessoa ou organização, como uma empresa ou um indivíduo;
• A entidade provedora é a pessoa ou organização que fornece um agente apropriado para
implementar um serviço específico;
• Uma entidade solicitante é uma pessoa ou organização que deseja fazer uso do Web
Service da entidade prestadora. Ele usará um agente solicitante para trocar mensagens
com o agente da entidade prestadora.
2. (FCC/SEFAZ-BA/AUDITOR FISCAL/TECNOLOGIA DA INFORMAÇÃO/PROVA

II/2019) Um Auditor Fiscal da área de Tecnologia da Informação observou que na orga-
nização onde trabalha há uma grande quantidade de softwares que necessitam validar
e inserir informações de contribuintes na base de dados. Cada um destes softwares é
mantido por um prestador de serviços diferente e foi escrito em linguagens de progra-
mação distintas. Pensando em uma arquitetura voltada a serviços, o Auditor recomen-
dou corretamente a criação de um
a. Enterprise Java Bean para incluir os dados dos contribuintes usando um serviço
CORBA para validar os dados de entrada.
b. método para validar e incluir contribuintes em cada aplicação, usando a mesma lógica
de validação e inclusão de dados.
c. serviço RESTful usando o protocolo SOAP para manter informações de estado nas
chamadas ao serviço, permitindo, assim, a consistência de estado na validação dos
dados de entrada do contribuinte.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services
d. portlet para que cada software possa converter os dados dos contribuintes para um
formato XML padrão e validá-los com base na mesma lógica centralizada.
e. web service para validar e incluir contribuintes, de forma que os demais softwares
possam simplesmente consumir esse serviço de maneira adequada.
COMENTÁRIO
a. Não suporta múltiplas linguagens.
b. Não é uma ideia boa.
c. RESTful não utiliza SOAP, e não mantém o estado da chamada de serviço.
d. O portlet são pequenos widgets e possuem sistemas distintos, contudo nem todo siste-
ma tem uma interface gráfica.
GABARITO
1. C
2. e
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services II
WEB SERVICES II
SISTEMAS DISTRIBUÍDOS
• Um sistema distribuído consiste em diversos agentes de software discretos que devem

trabalhar juntos para executar algumas tarefas.
• Assim, os sistemas separados se comunicam de alguma forma. O sistema distribuído
é assim chamado porque depende de sistemas ou softwares que estão executando
funções em vários computadores distintos.
• Além disso, os agentes em um sistema distribuído não operam no mesmo ambiente
de processamento. Portanto, eles devem se comunicar por pilhas de protocolos de
hardware/software em uma rede.
• Quando se tem um software rodando, com seus vários módulos, eles se comuni-
cam através do barramento de memória do computador (rápida e eficiente). Contudo,
quando se tem um sistema distribuído, ele se comunica através da rede de computa-
dores (mais lenta e restrita).
• Exemplo: a cópia de 1Gb para outro local do HD leva 10 segundos. Agora, o envio
desse mesmo arquivo por e-mail ou por algum serviço de nuvem demorará muito mais,
pois a comunicação entre o computador é mais rápida.
• Isso significa que as comunicações com um sistema distribuído são intrinsecamente
menos rápidas e confiáveis do que aquelas que usam invocação direta de código e
memória compartilhada.
5m
• Isso tem implicações arquitetônicas importantes, porque os sistemas distribuídos
exigem que os desenvolvedores (de infraestrutura e aplicativos) considerem a latên-
cia imprevisível do acesso remoto e levem em consideração problemas de simulta-
neidade e a possibilidade de falha parcial.
• Latência imprevisível diz respeito à velocidade, se ela será rápida ou lenta, e até
mesmo se será possível a comunicação.
• Problemas de simultaneidade: quando se está na máquina, o processo se comunica
com o outro. Contudo, quando se está em rede, existem centenas de clientes se comu-
nicando com o sistema central.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services II
• Falha parcial: considere que é necessário chamar vários web services, mas algum
falha. Nesse caso, será necessário avaliar qual o melhor procedimento para solucionar
o problema.
• Sistemas de objetos distribuídos são sistemas nos quais a semântica da inicialização
do objeto e chamada de método são expostos a sistemas remotos, através de uns
mecanismos proprietários ou padronizados para brokers de solicitações para além das
fronteiras do sistema.
• Sistemas de objetos distribuídos tipicamente são caracterizados por objetos que
mantêm um estado interno complexo necessário para suportar seus métodos, uma
interação refinada entre o objeto e o programa que o utiliza, e um foco em um sistema
de tipo de implementação compartilhado e hierarquia de interfaces entre o objeto e o
programa que o usa.
Obs.: Em suma, tem-se um sistema que é preparado para trabalhar de forma distribuída.
Por exemplo, suponha que existe um sistema que possui vários módulos que se
comunicam e fazem abertura de contas. Para transformar isso em um sistema no
web service, bastaria transformar em módulos e colocar cada um em um web ser-
vice diferente? Não, pois a forma como um módulo se comunicava com o outro era
muito intensa e será necessário mudar a lógica do sistema para que ele se torne um
sistema de objeto distribuído. Portanto, quando se altera um sistema de execução da
máquina para um sistema de objeto distribuído, isso terá implicações arquitetônicas,
principalmente no sistema de comunicação entre os módulos.
• Uma Arquitetura Orientada a Serviços (SOA) é uma forma de arquitetura de sistemas

distribuídos que geralmente é caracterizada pelas seguintes propriedades:
– Visualização lógica: o serviço é uma visualização lógica e abstrata de programas,
bancos de dados, processos de negócios etc., definidos em termos do que faz, geral-
mente executando uma operação em nível de negócios.
– Orientação da mensagem: o serviço é formalmente definido em termos das men-
sagens trocadas entre o agente provedor e o agente solicitante, e não nas proprie-
dades dos próprios agentes. A estrutura interna de um agente, incluindo recursos
como linguagem de implementação, estrutura de processos e até estrutura de banco
de dados, é deliberadamente abstraída na SOA. Um dos principais benefícios disso
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services II
diz respeito aos chamados sistemas legados. Ao evitar qualquer conhecimento da

estrutura interna de um agente, é possível incorporar qualquer componente ou apli-
cativo de software que possa ser "encapsulado" no código de tratamento de mensa-
gens que permita a ele aderir à definição formal de serviço.
10m
– Orientação da descrição: um serviço é descrito por metadados processáveis por
máquina. A descrição suporta a natureza pública da SOA: somente os detalhes
expostos ao público e importantes para o uso do serviço devem ser incluídos na des-
crição. A semântica de um serviço deve ser documentada, direta ou indiretamente,
por sua descrição.
– Granularidade: os serviços tendem a usar um pequeno número de operações
com mensagens relativamente grandes e complexas.
– Orientação de rede: os serviços tendem a ser orientados ao uso em uma rede,
embora isso não seja um requisito absoluto.
– Neutralidade de plataforma: as mensagens são enviadas em um formato padroni-
zado e neutro da plataforma, entregue pelas interfaces. XML é o formato mais óbvio
que atende a essa restrição.
WEB SERVICES E ESTILOS ARQUITETÔNICOS
• Os sistemas de objetos distribuídos têm vários desafios arquitetônicos:

– problemas introduzidos pela latência e falta de confiabilidade do transporte
subjacente;
15m
– a falta de memória compartilhada entre o chamador e o objeto;
– os numerosos problemas introduzidos pelos cenários de falha parcial;
– os desafios do acesso simultâneo a recursos remotos;
– a fragilidade dos sistemas distribuídos se atualizações incompatíveis forem introdu-
zidas para qualquer participante. Ex.: mudança de leiaute que quebra todas as apli-
cações que estão sendo chamadas.
• Em geral, os serviços SOA e Web são mais apropriados para aplicativos:
– que devem operar pela Internet, onde a confiabilidade e a velocidade não podem ser
garantidas;
– onde não há capacidade de gerenciar a implantação, para que todos os solicitantes
e fornecedores sejam atualizados de uma só vez;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services II
– onde os componentes do sistema distribuído são executados em diferentes platafor-

mas e produtos de fornecedores;
– onde um aplicativo existente precisa ser exposto para uso em uma rede e pode ser
agrupado como um Web Service;
WORLD WIDE WEB E A ARQUITETURA REST
• A World Wide Web opera como um sistema de informações em rede que impõe várias
restrições:
– os agentes identificam objetos no sistema, chamados recursos, com URIs (Uniform
Resource Identifiers);
– os agentes representam, descrevem e comunicam o estado do recurso por meio de
representações do recurso em uma variedade de formatos de dados amplamente
compreendidos (por exemplo, XML, HTML, CSS, JPEG, PNG);
– os agentes trocam representações por meio de protocolos que usam URls para iden-
tificar e abordar direta ou indiretamente os agentes e recursos;
Obs.: existe uma similaridade arquitetônica entre World Wide Web e Web Service.
• Um estilo de arquitetura ainda mais restrito para aplicativos confiáveis da Web, conhe-
cido como Representation State Transfer (REST), foi proposto por Roy Fielding e
inspirou o documento de arquitetura do W3C Technical Architecture Group e muitos
que o veem como um modelo de como construir Web Services;
• A Web REST é o subconjunto da WWW (com base no HTTP) no qual os agentes forne-
cem semântica uniforme de interface – essencialmente criam, recuperam, atualizam e
excluem – em vez de interfaces arbitrárias ou específicas de aplicativos, e manipulam
recursos apenas pela troca de representações;
20m
• Além disso, as interações REST são "sem estado" no sentido de que o significado de
uma mensagem não depende do estado da conversa;
DESENVOLVIMENTO WEB
Web Services II
Obs.: essa não é uma restrição tão grande no Web Service, mas no REST, sim. Neste não
existe um estado inicial, tudo estará na própria requisição.
Obs.: o Web Service tradicional se comunica mais na forma XML. O REST se comunica
com o JSON, que é menos restrito e menos formal.
Tecnologias de Web Services

É necessário um arcabouço tecnológico para se trabalhar com o Web Services. Veja:
DESENVOLVIMENTO WEB
Web Services II
SOAP
• O SOAP fornece uma estrutura padrão e extensível para empacotar e trocar men-
sagens XML.
• Define uma estrutura de mensagens baseada em XML: um modelo de processamento
e um modelo de extensibilidade. As mensagens SOAP podem ser transportadas por
uma variedade de protocolos de rede; como HTTP, SMTP, FTP, RMI / IIOP ou um pro-
tocolo de mensagens proprietário.
• Define três componentes opcionais: um conjunto de regras de codificação para expres-
sar instâncias de tipos de dados definidos por aplicativo, uma convenção para repre-
sentar chamadas e respostas a procedimentos remotos (RPC) e um conjunto de regras
para usar SOAP com HTTP.
• Embora o SOAP não seja definido como um acrônimo, há duas expansões do termo
que refletem essas diferentes maneiras pelas quais a tecnologia pode ser interpretada:
– Protocolo de Arquitetura Orientada a Serviços: uma mensagem SOAP repre-
senta as informações necessárias para chamar um serviço ou reflete os resultados
de uma chamada de serviço e contém as informações especificadas na definição da
interface de serviço.
– Protocolo de Acesso a Objetos Simples: ao usar a representação SOAP RPC
opcional, uma mensagem SOAP representa uma chamada de método em um objeto
remoto e a serialização na lista de argumentos desse método que deve ser movida
do ambiente local para o ambiente remoto.
Exemplo de uma mensagem SOAP:

25m
DESENVOLVIMENTO WEB
Web Services II
WSDL
• WSDL é uma linguagem para descrever Web Services.

• O WSDL descreve os Web Services começando com as mensagens que são trocadas
entre o solicitante e os agentes do provedor. As próprias mensagens são descritas de
maneira abstrata e depois vinculadas a um protocolo de rede e formato de mensagem
concretos.
• As definições de serviço da Web podem ser mapeadas para qualquer linguagem de
implementação, plataforma, modelo de objeto ou sistema de mensagens.
• Extensões simples à infraestrutura existente da Internet podem implementar Web Ser-
vices para interação por meio de navegadores ou diretamente dentro de um aplicativo.
• O aplicativo pode ser implementado usando COM, JMS, CORBA, COBOL ou qualquer
número de soluções de integração proprietárias.
• Desde que o remetente e o destinatário concordem com a descrição do serviço (por
exemplo, arquivo WSDL), as implementações por trás dos Web Services podem ser
em qualquer linguagem.
ATENÇÃO
Perceba que no Web Service não importa a linguagem de implementação dos dados, pois
ele é um estilo arquitetônico que independe disso.
Exemplo de Web Service:

ANOTAÇÕES
DESENVOLVIMENTO WEB
Web Services II
DIRETO DO CONCURSO
1. (IDECAN/IF-PB/PROFESSOR/INFORMÁTICA/2019) Sobre o estilo arquitetural REST

(Representational State Transfer), é correto afirmar que
a. a resposta das requisições é sempre feita no formato JSON, o que impossibilita a
implementação de aplicativos móveis.
b. faz uso de operações que mantêm informações sobre a sessão no lado recebedor,
sendo assim chamada de stateless.
c. algumas de suas restrições incluem arquitetura cliente-servidor, statelessness, sis-
tema em camadas e interface uniforme.
d. surgiu recentemente, no ano de 2010, como resultado dos esforços da Google.
e. faz uso apenas dos verbos GET e POST, do HTTP.
COMENTÁRIO
a. A resposta das requisições não é sempre feita no formato JSON.
b. O nome não é stateless.
d. O surgimento ocorreu com Roy Fielding, e não foi em 2010.
e. Podem ser usados qualquer um dos métodos HTTP.
Veja:
World Wide Web e a Arquitetura REST
• Um estilo de arquitetura ainda mais restrito para aplicativos confiáveis da Web, conheci-
do como Representation State Transfer (REST), foi proposto por Roy Fielding e inspirou o
documento de arquitetura do W3C Technical Architecture Group e muitos que o veem como
um modelo de como construir Web Services.
• A Web REST é o subconjunto da WWW (com base no HTTP) no qual os agentes for-
necem semântica uniforme de interface – essencialmente criam, recuperam, atualizam
e excluem – em vez de interfaces arbitrárias ou específicas de aplicativos, e manipulam
recursos apenas pela troca de representações.
• Além disso, as interações REST são "sem estado" no sentido de que o significado de
uma mensagem não depende do estado da conversa.
2. (FCC/SEFAZ/BA/AUDITOR FISCAL/ADMINISTRAÇÃO, FINANÇAS E CONTROLE

INTERNO/2019) Os web services são componentes de software na web que podem
fornecer determinados serviços a aplicações criadas em diferentes linguagens. Podem
usar o protocolo SOAP para transferência de mensagens em formato XML. Para des-
crever a estrutura destas mensagens geralmente utiliza-se
30m
DESENVOLVIMENTO WEB
Web Services II
a. REST.
b. WSDL.
c. CORBA.
d. RESTFUL.
e. HTML.
COMENTÁRIO
Utiliza-se o WSDL.
Veja:
• WSDL é uma linguagem para descrever Web Services.
• O WSDL descreve os Web Services começando com as mensagens que são trocadas
entre o solicitante e os agentes do provedor. As próprias mensagens são descritas de
maneira abstrata e depois vinculadas a um protocolo de rede e formato de mensagem
concretos.
• As definições de serviço da Web podem ser mapeadas para qualquer linguagem de im-
plementação, plataforma, modelo de objeto ou sistema de mensagens.
• Extensões simples à infraestrutura existente da Internet podem implementar Web Servi-
ces para interação por meio de navegadores ou diretamente dentro de um aplicativo.
GABARITO
1. c
2. b
ANOTAÇÕES
DESENVOLVIMENTO WEB
SOA – Service Oriented Architecture
SOA – SERVICE ORIENTED ARCHITECTURE
Bibliografia:
Disponível em: https://linux.ime.usp.br/~cef/mac499-06/monografias/filipemadeira/monografia.pdf
DESENVOLVIMENTO WEB
O que é SOA?
SOA é uma abordagem arquitetural corporativa que permite a criação de serviços de

negócio interoperáveis que podem facilmente ser reutilizados e compartilhados entre aplica-
ções e empresas. (Gartner Group)
Ou seja, SOA é uma forma de organizar serviços em uma empresa de forma que eles
possam ser consumidos por diversas aplicações, formando a composição dessas aplicações.
Esse tipo de abordagem de SOA é mais comum em grandes empresas, em que vários ser-
viços menores podem ser utilizados para compor um serviço maior (operação de negócios).
Cada serviço é distinto e feito em um módulo separado do sistema. Posteriormente, esses
módulos são compostos e formam o serviço principal.
5m
Qual é a definição de SOA?
SOA não é uma tecnologia. Há tanto de negócio quanto de tecnologia em SOA. As tec-
nologias (padrões) que dão suporte a SOA são o que a viabiliza, mas SOA não é uma tecno-
logia por si só;
SOA não é uma metodologia. Há várias metodologias (processos, ferramentas, méto-

dos de trabalho) que podem ser usados para implantar SOA com sucesso. SOA não é nem
define alguma metodologia;
SOA pode ser considerada uma filosofia arquitetural. SOA é uma linha de pensa-
mento que permeia a implementação de necessidades de negócio, refletida em diretrizes,
políticas e metodologias corporativas, não necessariamente restritas à área de TI;
SOA não é algo que se possa comprar ou instalar;

SOA não é um webservice;
SOA não cria nada. Ela apenas sugere, propõe, define;
SOA baseia-se no conceito do uso de serviços atômicos, independentes e com
baixo acoplamento.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Obs.: um serviço atômico é aquele que não depende de um outro estado. Além disso, ou
ele dá certo ou ele dá errado. Ex.: em uma empresa de seguros, registrar apólice é
um dos serviços. Nesse caso, insere-se os dados da apólice e do cliente, sendo que,
no final, esse serviço dará certo ou errado, não ficando no meio termo. O baixo aco-
plamento é a menor dependência de outros serviços possível.
SOA busca disponibilizar as funcionalidades de um sistema como um serviço.

Dessa forma, essas funcionalidades podem ser compartilhadas e reutilizadas entre apli-
cações. Seu principal objetivo é ser mais flexível em atender às necessidades do mercado.
Obs.: nesse sentido, na contratação de um seguro, um banco pode possuir um serviço

chamado “atualização cadastral”. Tal serviço pode ser compartilhado na contratação
de outros serviços bancários que também consumam esse serviço denominado “atu-
alização cadastral”.
Em 1996, os pesquisadores do Gartner Roy Schulte e Yefim Natis mencionaram pela

primeira vez o conceito do SOA em um artigo. Os usuários dessa abordagem ganham em
flexibilidade, agilidade e redução de custos na reutilização de serviços.
10m
Um dos componentes mais importantes do SOA é o Enterprise Service Bus (ESB), um
barramento de serviços corporativos.
Obs.: esse barramento é um canal que existirá para que as aplicações possam consumir
os serviços. Em regra, o ideal é que esse canal seja único.
Esse barramento disponibiliza com maior facilidade os serviços do sistema para os usu-
ários e outras aplicações, acelerando processos de integração.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Exemplo:
Obs.: é importante perceber que esse barramento também é um ponto de falha bastante
perigoso, pois, caso ele saia do ar, todos os sistemas ligados a ele irão falhar. Assim,
é importante que ele seja muito bem implementado e que possua mecanismos para
se evitar falhas, pois, caso ele fique indisponível, isso pode indisponibilizar o funcio-
namento da empresa como um todo.
Vantagens
O alinhamento com as regras de negócio é um dos maiores benefícios desse tipo de

arquitetura.
Outras vantagens são:
• A diminuição do tempo de desenvolvimento;
• O baixo acoplamento entre as partes do sistema facilita a manutenção;
• O isolamento da estrutura de um serviço traz flexibilidade durante mudanças;
• Facilidade de agregar novas tecnologias a plataformas;
• Possibilidade de reutilização de componentes.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Orientação a Serviços
Em essência, trata-se de um paradigma criado com o objetivo de desenvolver sistemas

modularizados, o que traz diversos benefícios ao produto final.
15m
Ao invés de desenvolvermos grandes aplicações como um único bloco, podemos encap-
sular algumas funções importantes e disponibilizá-las na forma de serviços em uma rede.
Obs.: esse único bloco também é conhecido como monolito (ou aplicação monolítica), que
é uma aplicação formada por um grande bloco. Atualmente, essa não é considerada
uma boa prática.
A arquitetura propõe padrões e práticas de desenvolvimento para possibilitar que os ser-

viços (web services) possam interagir adequadamente em um ambiente tão heterogêneos
quanto a Internet, por exemplo, ou em outra rede qualquer.
Como qualquer arquitetura baseada em componentes, SOA mantém a independência de
cada um deles e define, apenas, como será feita a comunicação entre eles.
Características
SOA é um paradigma de desenvolvimento de software que visa a permitir que os compo-

nentes de um processo de negócio sejam integrados mais facilmente.
Um componente de um processo de negócio é uma atividade comum, algo que é reali-
zado frequentemente naquele processo de negócio específico.
O objetivo do SOA é implementar um sistema que represente o negócio do cliente, divi-
dindo este negócio em processos e estes em atividades (funções de negócio).
Algumas das características são:
• Baixo acoplamento (loose coupling) – Os serviços mantêm um relacionamento que
minimiza as dependências e só mantém a consciência um do outro;
• Contrato de serviço – Os serviços aderem a um contrato de comunicação definido
coletivamente por um ou mais documentos de descrição de serviço;
• Abstração de serviços – Além do que é descrito no contrato de serviço, os serviços
escondem a lógica do mundo exterior;
ANOTAÇÕES
DESENVOLVIMENTO WEB
• Reutilização de serviços – A lógica é dividida em serviços com a intenção de promo-

ver a reutilização;
• Composição do serviço – As coleções de serviços podem ser coordenadas e monta-
das para formar serviços compostos;
20m
• Autonomia do serviço – Os serviços têm controle sobre a lógica que eles encapsulam;
• Otimização de serviços – Serviços de alta qualidade são geralmente considerados
preferíveis aos de baixa qualidade;
• Descoberta de serviços – Os serviços são projetados para serem descobertos por
meios externos, para que possam ser encontrados e avaliados através dos mecanis-
mos de descoberta disponíveis.
Obs.: em muitos casos, será feito um catálogo de serviços em uma fonte central. Dessa
forma, quando for feita uma nova operação, será possível consultar esse catálogo e
reutilizar serviços que já estão prontos em um novo processo de negócio.
Diagrama de funcionamento:
ANOTAÇÕES
DESENVOLVIMENTO WEB
Benefícios do SOA
Em geral, a criação de serviços resulta em um bom índice de reaproveitamento, o que pos-

sibilita a redução de custos de projeto e desenvolvimento, e diminui o tempo total do projeto.
A SOA possibilita isto apenas porque este é um paradigma focado, através dos serviços,
nos valores e processos de negócio.
A aplicação torna-se, assim, tão ágil quanto o negócio em si e qualquer mudança no
negócio é facilmente transmitida para o sistema, rearranjando as funcionalidades que já
estão disponíveis através dos serviços e desenvolvendo a lógica restante.
Dentre os benefícios, destacam-se:
• Reuso de código;
• Redução de redundâncias de funcionalidades;
• Redução do custo de manutenção.
Padrões Utilizados
O ciclo de vida de um serviço envolve diversas fases e cada uma destas fases tem um
padrão a ser adotado para que o serviço seja corretamente especificado.
Um serviço deve seguir padrões com relação ao formato do protocolo de mensagens,
assim como com relação à forma de descrevê-lo ou torná-lo disponível em um serviço de
diretórios.
Obs.: nesse sentido, o SOA irá focar bastante no padrão de como um serviço irá se comu-
nicar com o outro, muito mais do que na forma de implementação do serviço em si.
25m
Os padrões comumente utilizados são:

• XML como a linguagem responsável por representar tipos de dados e compor as
mensagens;
• SOAP como o protocolo de troca de mensagens XML;
• HTTP como o protocolo responsável pelo envio das mensagens;
• WSDL para descrever o serviço e UDDI para listar os serviços na rede.
ANOTAÇÕES
DESENVOLVIMENTO WEB
XML
XML é uma linguagem baseada em texto e é totalmente independente de plataforma.

Desse modo, esta linguagem é ideal para a troca de mensagens entre plataformas, que
é algo muito comum de ocorrer entre serviços, que, provavelmente, estão em plataformas
distintas.
Com XML, a informação é organizada de uma forma hierárquica, parecida com uma
árvore, onde os marcadores mais internos são imediatamente dependentes do marcador que
está no nível superior a estes.
Este tipo de estrutura, aliada aos marcadores com valor semântico, permite que os algo-
ritmos responsáveis por analisar a mensagem sejam simples e eficientes.
Obs.: a principal vantagem do XML é que ele pode mostrar qualquer tipo de dado. Existem
várias ferramentas nas linguagens de programação para tratar esses arquivos XML.
Exemplo:
ANOTAÇÕES
DESENVOLVIMENTO WEB
Simple Object Acess Protocol (SOAP)
SOAP é um protocolo baseado em XML que é utilizado para definir um modo uniforme de
transmitir dados representados no formato XML.
Ele é um protocolo para troca de mensagens de via única e que não guarda informações
sobre interações anteriores (stateless).
Este protocolo não é responsável pelo envio em si da mensagem, mas sim por um con-
ceito conhecido como envelope.
O protocolo SOAP encapsula a mensagem e agrega informações tais como a quem se
destina a mensagem, exatamente como um envelope de uma carta.
HyperText Transfer Protocol (HTTP)
HTTP é um protocolo da camada de aplicação que se tornou o protocolo padrão de trans-

ferência de dados na Internet.
Uma requisição utilizando HTTP consiste em um cliente iniciando uma conexão TCP
(Transfer Control Protocol), protocolo da camada de transporte responsável por dividir as
mensagens em pacotes e enviá-las através de uma rede, com um servidor em um ponto dis-
tinto da rede.
A requisição é enviada a uma porta específica onde o servidor já monitora a entrada de
requisições e, após processar a requisição, o servidor envia uma mensagem de resposta que
será a informação requisitada ou alguma mensagem de erro.
Uma variação comum do HTTP é o HTTPS (HTTP over Secure Socket Layer). Neste
caso, a camada de segurança (SSL) criptografa a mensagem antes do envio.
30m
Web Services Description Language (WSDL)
WSDL é um protocolo também baseado em XML que é responsável por revelar o que um
serviço pode fazer, onde ele está, como invocá-lo e quais tipos de dados enviar ao serviço ou
seja ele descreve a interface de um serviço.
Através da descrição no formato determinado pelo protocolo WSDL, tem-se acesso a
todas as informações necessárias para realizar a comunicação com um certo serviço.
ANOTAÇÕES
DESENVOLVIMENTO WEB
As informações importantes para a comunicação são os formatos das mensagens de

entrada e saída a serem trocadas nas interações com o serviço, as operações suportadas
pelo mesmo, os tipos de dados utilizados nestas interações, o endereço onde o serviço pode
ser encontrado e as interfaces de ligação (binding).
Universal Description, Discovery and Integration (UDDI)
UDDI também é um protocolo baseado em XML e é utilizado para descrever, descobrir

e gerenciar os serviços na rede. Através deste protocolo, existe uma maneira padronizada
dos serviços descreverem a si próprios e, assim, tornarem-se disponíveis a quem possa
utilizá-los.
UDDI prove um diretório de serviços, algo que pode ser comparado com uma "lista
telefônica de serviços" tanto pela utilidade quanto pela forma como as informações estão
organizadas.
Ao publicarmos um serviço, temos que disponibilizar diversas informações para que um
provável usuário deste serviço possa encontrá-lo de forma mais fácil.
Relação:
ANOTAÇÕES
DESENVOLVIMENTO WEB
DIRETO DO CONCURSO
1. (2013/CESPE/MPOG/TECNOLOGIA DA INFORMAÇÃO) No que se refere ao SOA
(service-oriented architeture), julgue o item a seguir.
O SOA promove a integração entre o negócio e a tecnologia da informação por meio de

serviços, que são o principal componente dessa arquitetura.
COMENTÁRIO
Item correto, pois traz o conceito de SOA.
2. (2011/CESGRANRIO/PETROBRAS/ANALISTA DE SISTEMAS JÚNIOR) O principal

uso da internet (www) é o acesso interativo a documentos e aplicações, na maioria
dos casos, acessados por pessoas. Entretanto, cresce significantemente o uso dessa
arquitetura para comunicação e interoperabilidade através do web-service. Em geral, os
webservices oferecem serviços para sua descoberta e para sua descrição, representa-
dos, respectivamente, por:
a. SOAP e WSDL
b. UDDI e SOAP
c. UDDI e WSDL
d. URI e SOAP
e. URI e WSDL
COMENTÁRIO
A descoberta é realizada por meio do UDDI, já a descrição é feita por meio do WSDL.
35m
GABARITO
1. C
2. c
preparada e ministrada pelo professor Tiago Lage Payne.
DESENVOLVIMENTO WEB
REST - Representational State Transfer
REST – REPRESENTATIONAL STATE TRANSFER
Bibliografia
https://www.codecademy.com/articles/what-is-rest
https://www.devmedia.com.br/rest-tutorial/28912
https://www.oracle.com/technetwork/articles/java/restful-142517.html
A bibliografia mais importante sobre REST é a tese de doutorado do Roy Thomas Fielding.
O conceito de REST surgiu a partir dessa tese que se opunha à maneira como as coisas eram
feitas, principalmente com relação a complexidade: ele simplificou utilizando protocolos mais
leves. O “pai” do REST é Roy Fielding.
Essa tese é um pouco longa e os conceitos já foram atualizados desde então. Existem
vários outros artigos, mais curtos e mais atuais que são recomendados.
Definição de REST
• REST, ou REpresentational State Transfer (Transferência de Estado Representa-
cional), é um estilo arquitetural que fornece padrões entre sistemas de computador
na Web, facilitando a comunicação entre os sistemas.
• Os sistemas compatíveis com REST, geralmente chamados de sistemas RESTful, são carac-
terizados pela falta de estado e por separar as responsabilidades do cliente e do servidor;
• Possibilita a criação de web services, cujas principais diferenças em relação ao modelo
5m tradicional (SOAP) estão na:
°° Utilização semântica dos métodos HTTP (GET, POST, PUT e DELETE);
°° Leveza dos pacotes de dados transmitidos na rede;
°° Simplicidade, fazendo desnecessária a criação de camadas intermediárias (Ex.:
Envelope SOAP) para encapsular os dados;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Separação entre Cliente e Servidor

• A implementação do cliente e do servidor podem ser feitas independentemente, sem
que cada um tenha conhecimento do outro;
• Isso significa que o código no lado do cliente pode ser alterado a qualquer momento
sem afetar a operação do servidor, e o código no lado do servidor pode ser alterado sem
afetar a operação do cliente;
• Desde que cada lado saiba qual formato de mensagens enviar para o outro, eles podem
10m ser mantidos modulares e separados;
• Separando as preocupações da interface do usuário das preocupações de armazena-
mento de dados, melhora-se a flexibilidade da interface entre as plataformas;
• A separação permite que cada componente evolua independentemente;
• Usando uma interface REST, diferentes clientes atingem os mesmos pontos de extremi-
dade REST, executam as mesmas ações e recebem as mesmas respostas;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Sem Estado
• Os sistemas que seguem o paradigma REST são sem estado, o que significa que o ser-
vidor não precisa saber nada sobre o estado do cliente e vice-versa;
• Dessa maneira, tanto o servidor quanto o cliente podem entender qualquer mensagem
recebida, mesmo sem ver as mensagens anteriores;
• Essa restrição é imposta pelo uso de recursos, em vez de comandos;
• Recursos são os substantivos da Web - eles descrevem qualquer objeto, documento
ou coisa que você pode precisar armazenar ou enviar para outros serviços;
• Essas restrições ajudam os aplicativos RESTful a obter confiabilidade, desempenho
rápido e escalabilidade, como componentes que podem ser gerenciados, atualizados e
reutilizados sem afetar o sistema como um todo, mesmo durante a operação do sistema;
Comunicação entre Cliente e Servidor

15m Na arquitetura REST, os clientes enviam solicitações para recuperar ou modificar recur-
sos, e os servidores enviam respostas para essas solicitações;
Realizando Requisições
REST requer que um cliente faça uma solicitação ao servidor para recuperar ou modificar
dados no servidor. Uma solicitação geralmente consiste em:
• Um verbo HTTP, que define o tipo de operação a ser executada;
• Um cabeçalho, que permite ao cliente passar informações sobre o pedido;
• Um caminho para um recurso;
• Um corpo de mensagem opcional contendo dados;
Verbos HTTP
Existem 4 verbos HTTP básicos que usamos em pedidos para interagir com recursos em
um sistema REST:
• GET – recupera um recurso específico (por id) ou uma coleção de recursos;
• POST – cria um recurso;
• PUT – atualiza um recurso específico por id;
• DELETE – remove um recurso específico por id;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Cabeçalhos
• No cabeçalho da solicitação, o cliente envia o tipo de conteúdo que pode receber do
servidor. Isso é chamado de campo "accept" e garante que o servidor não envie dados
que não possam ser compreendidos ou processados pelo cliente;
• Por exemplo, um arquivo de texto contendo HTML seria especificado com o tipo "text/
html";
Um arquivo de texto genérico seria denotado como "text/plain".
Ex.: GET /articles/23
Accept: text/html, application/xhtml
Caminhos (URL)
• As solicitações devem conter um caminho para um recurso no qual a operação deve ser
executada. Nas APIs RESTful, os caminhos devem ser projetados para ajudar o cliente
a saber o que está acontecendo;
• Convencionalmente, a primeira parte do caminho deve ser a forma plural do recurso.
Isso mantém os caminhos aninhados simples de ler e fáceis de entender;
• Por exemplo, um caminho como: fashionboutique.com/customers/223/orders/12
• É claro no que ele aponta, mesmo que você nunca tenha visto esse caminho especí-
fico antes, porque é hierárquico e descritivo. Podemos ver que estamos acessando o
pedido com id 12 para o cliente com id 223;
• Os caminhos devem conter as informações necessárias para localizar um recurso com
20m
o grau de especificidade necessário. Ao se referir a uma lista ou coleção de recursos,
não é necessário adicionar um ID a uma solicitação POST para um caminho fashion-
boutique.com/customers que não precisaria de um identificador extra, pois o servidor
gerará um id para o novo objeto;
• Se estamos tentando acessar um único recurso, precisaríamos acrescentar um ID ao
caminho;
• Por exemplo: GET fashionboutique.com/customers/:id - recupera o item no recurso de
clientes com o ID especificado
DELETE fashionboutique.com/customers/:id - exclui o item no recurso de clientes com o
ID especificado.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Enviando Respostas
Tipos de Conteúdos
• Nos casos em que o servidor está enviando dados para o cliente, o servidor deve incluir
um "content-type" no cabeçalho da resposta;
• Esse campo de cabeçalho do tipo de conteúdo alerta o cliente para o tipo de dados que
está enviando no corpo da resposta;
• Esses tipos de conteúdo são tipos MIME, assim como estão no campo "accept" do
cabeçalho da solicitação;
• O tipo de conteúdo que o servidor envia de volta na resposta deve ser uma das opções
que o cliente especificou no campo "accept" da solicitação;
Exemplo:
Requisição
GET /articles/23 HTTP/1.1
Accept: text/html, application/xhtml
Resposta
HTTP/1.1 200 (OK)
Content-Type: text/html
Códigos de Resposta
25m • As respostas do servidor contêm códigos de status para alertar o cliente sobre informa-
ções sobre o sucesso da operação;
• Para cada verbo HTTP, há códigos de status esperados que um servidor deve retornar
após sucesso:
• GET – returna 200 (OK)
• POST – returna 201 (CREATED)
DESENVOLVIMENTO WEB
• PUT – returna 200 (OK)

• DELETE – returna 204 (NO CONTENT) Se a operação falhar, retorne o código de
status mais específico possível, correspondente ao problema encontrado.
Exemplo de requisição/resposta
• Obter a lista de clientes
Requisição
GET http://fashionboutique.com/customers Accept: application/json
Resposta:
Status Code: 200 (OK)
Content-type: application/json
• Cadastrar um cliente
Requisição
POST http://fashionboutique.com/customers
Body:
{
“customer”: {
“name” = “Scylla Buss”
“email” = “scylla.buss@codecademy.org”
}
}
Resposta:
201 (CREATED)
• Obter um cliente específico
GET
http://fashionboutique.com/customers/123
Accept: application/json
Resposta:
Status Code: 200 (OK)
DIRETO DO CONCURSO
1. (2017/CESPE/TRE-PE/ANALISTA JUDICIÁRIO/ANÁLISE DE SISTEMAS) REST (repre-
30m
sentational state transfer) é:
a. um estilo de desenvolvimento que utiliza o protocolo HTTP e se baseia na interação
simples entre cliente e servidor.
b. um software de infraestrutura em um sistema distribuído que auxilia no gerenciamento
DESENVOLVIMENTO WEB
de interações entre entidades distribuídas em serviços web.

c. uma linguagem web voltada a definição de predicados que se apliquem a classes de
objetos e de interações em um modelo U M L.
d. uma linguagem de programação com tipos dinâmicos, voltada principalmente para de-
senvolvimento de aplicações web.
e. um modelo de desenvolvimento de software estruturado e organizado como um conjun-
to de classes de objeto e de relações entre essas classes.
COMENTÁRIO
a) um estilo de desenvolvimento que utiliza o protocolo HTTP e se baseia na interação
simples entre cliente e servidor.
b) um software de infraestrutura em um sistema distribuído que auxilia no gerenciamento de
interações entre entidades distribuídas em serviços web (REST não é um software);
c) uma linguagem web voltada a definição de predicados que se apliquem a classes de
objetos e de interações em um modelo U M L (REST não é uma linguagem web);
d) uma linguagem de programação com tipos dinâmicos, voltada principalmente para
desenvolvimento de aplicações web (REST não é uma linguagem);
e) um modelo de desenvolvimento de software estruturado e organizado como um conjunto
de classes de objeto e de relações entre essas classes (REST não é software).
GABARITO
1. a
preparada e ministrada pelo professor Tiago Pádua.
ministrado na videoaula. Não recomendamos a substituição do estudo em vídeo pela leitura
ANOTAÇÕES
LINGUAGEM DE PROGRAMAÇÃO
GraphQL
GRAPHQL
Obs.: A imagem acima apresenta a página inicial GraphQL.
As integrações entre aplicações começaram a ocorrer no início da computação com

arquivos de texto e, posteriormente, passou a ser necessário, principalmente com o advento
da internet, uma toca de dados mais dinâmica.
A troca de dados através de arquivos, geralmente ocorre no final do dia, em um momento
específico e não online.
Para a comunicação online entre sistemas, iniciou-se a criação de alguns padrões:
• Web service
• APIs rest
Obs.: Corresponde a uma simplificação da forma de troca de informação do sistema.
O API rest teve uma grande adesão e, atualmente, é considerado como a forma mais
popular de troca de informações no sistema.
• GraphQL – É considerado como uma evolução do API rest.

ANOTAÇÕES
GraphQL
Obs.: Ao realizar uma requisição de API rest, não haverá controle sobre os dados de res-
posta, enquanto o GraphQL permite consultas dinâmicas.
5m
O API rest economiza a taxa de transferência e produz uma resposta menor.
• GraphQL é uma linguagem de consulta para APIs e um runtime para atender a essas
consultas com seus dados existentes;
Obs.: Runtime – Ambiente de execução.
• O GraphQL fornece uma descrição completa e compreensível dos dados em sua API,
oferece aos clientes o poder de solicitar exatamente o que eles precisam e nada mais,
facilita a evolução de APIs ao longo do tempo e permite ferramentas de desenvolvedor
poderosas;
Obs.: Atualmente o API rest possui uma especificação denominada open APF.
No API rest a resposta possui um formato específico, enquanto o GraphQL fornece um

padrão de customização da resposta.
A API será considerada deprecada quando for necessário versionar a API.
O GraphQL não está vinculado a nenhum banco de dados específico e nem a mecanis-
mos de armazenamento.
Obs.: O GraphQL pode ser utilizado para a base de dados relacionais.

ANOTAÇÕES
GraphQL
Obs.: No GraphQL é possível interferir diretamente na resposta.

10m
ANOTAÇÕES
GraphQL
• Uma consulta GraphQL para uma API obtém exatamente o necessário, nada mais e
nada menos;
• As consultas do GraphQL sempre retornam resultados previsíveis;
• Os aplicativos que usam o GraphQL são rápidos e estáveis porque controlam os dados
que obtêm, não o servidor;
Obs.: As consultas podem ser interativas, tendo em vista que a ferramenta disponibilizada
na página permite a realização dessas consultas.
• As consultas do GraphQL acessam não apenas as propriedades de um recurso, mas

também seguem facilmente as referências entre eles;
Obs.: O GraphQL foi desenvolvido pelo Facebook, visando melhorar suas próprias APIs.
Ex.: Um usuário possui uma lista de “friends”. Considerando o banco de dados rela-
cional, pode-se dizer que há uma relação de um para muitos, ou seja, um usuário possui
muitos amigos.
Para retornar o usuário e os três primeiros amigos, será necessário realizar quatro requi-
sições: uma para pegar o usuário e três para pegar os amigos.
Obs.: É possível solicitar os dados do usuário e dos amigos em uma única query.
• Embora as APIs REST típicas exijam carregamento de várias URLs, as APIs do Gra-
phQL obtêm todos os dados de que o aplicativo precisa em uma única solicitação;
Obs.: No caso do GraphQL, serão submetidas várias querys distintas para uma URL única
e, dependendo da query submetida, será retornada uma informação diferente.
• Os aplicativos que usam o GraphQL podem ser rápidos mesmo em conexões de rede
móvel lentas;
ANOTAÇÕES
GraphQL
15m
GraphQL
Obs.: Através do GraphQL é possível percorrer outros elementos que irão retornar os da-
dos sem perda de banda desnecessária.
• As APIs do GraphQL são organizadas em termos de tipos e campos, não de endpoints;
Obs.: No API rest há um conjunto de endpoints, sendo que cada URL vai devolver
um recurso.
O GraphQL terá primeiro uma definição dos elementos que estão disponíveis com
tipos e campos.
Obs.: A segunda imagem apresenta as entidades e as query que podem ser realizadas.
ANOTAÇÕES
GraphQL
• É possível acessar todos os recursos de dados a partir de um único endpoint;

• O GraphQL usa tipos para garantir que os aplicativos apenas perguntem o que é pos-
sível e forneçam erros claros e úteis;
• Os aplicativos podem usar tipos para evitar escrever código de análise manual;
Obs.: Os aplicativos podem consumir a tipagem no GraphQL, visando ter uma expectativa
correta de qual tipo de dados irá receber.
• Novos campos e tipos podem ser adicionados à sua API GraphQL sem afetar as con-
sultas existentes;
Obs.: Não será necessário versionar, pois, as querys antigas continuarão sendo
apresentadas.
• Os campos podem ser descontinuados e ocultos das ferramentas;

• Ao usar uma única versão em evolução, as APIs do GraphQL fornecem aos aplicativos
acesso contínuo a novos recursos e incentivam um código de servidor mais limpo e
sustentável;
ANOTAÇÕES
GraphQL
Obs.: Com o uso em larga escala do rest, percebeu-se que possuía algumas deficiências
como o retorno sempre numa escala fixa de campos, entre outros.
20m
No API Rest, à medida que vai versionando, serão geradas bases de códigos repetidas.
• O GraphQL cria uma API uniforme em todo o aplicativo sem ser limitado por um meca-
nismo de armazenamento específico;
• As APIs GraphQL que aproveitam os dados e códigos existentes com engines Gra-
phQL disponíveis em vários linguagens;
• São fornecidas funções para cada campo no sistema de tipos e o GraphQL as chama
de forma concorrente;
ANOTAÇÕES
GraphQL
GraphQL
Obs.: Na primeira imagem, observa-se que a definição é realizada em termos de sequência.
O GraphQL irá funcionar como uma ponte para receber a requisição com a query e acio-
nar as funções para gerar respostas adequadas.
Após o serviço de GraphQL estiver em execução, poderá receber e consultar as operações.
25m
Obs.: Observa-se que a quantidade de dados que trafega no GraphQL é pequena.
�Este material foi elaborado pela equipe pedagógica do Gran Concursos, de acordo com a aula pre-
parada e ministrada pelo professor Tiago Pádua.
ANOTAÇÕES
CONHECIMENTOS ESPECÍFICOS
GraphQL II
GRAPHQL II
Obs.: GraphQL é uma linguagem e um ambiente de execução que permite uma evolu-
ção nas APIs.
O GraphQL foi desenvolvido pelos engenheiros do Facebook com o objetivo de resolver

os problemas da rede social e também é utilizado por outras empresas que compartilham os
mesmos problemas.
Obs.: Na imagem acima apresenta um formato proprietário onde percorreu o grafo das
informações.
Consultas e Mutações: Argumentos

ANOTAÇÕES
GraphQL II
Obs.: há a possibilidade de passar alguns argumentos, sendo possível dar um dado a mais.
Ex.: Uma query dos”humanos” com o ID número 1.000 retornou um dado específico,
sendo que na query anterior foram voltados todos os dados.
Caso não fosse possível passar os argumentos o GraphQL não teria utilidade, sendo que
para passar o argumento, é necessário acrescentar o valor seguido de dois pontos.
No Rest, em geral, o ID é passado na URL.
Os parâmetros apresentados podem servir de conversão de dados.
No Rest, é possível passar um parâmetro como ID, porém no caso apresentado acima,
foi realizada uma conversão de unidade para “pés”.
5m
Consultas e Mutações: Apelidos
Obs.: Apelidos = Alius.
No GraphQL há a possibilidade de renomear os campos, como apresentado na imagem

acima, não sendo possível no Rest.
ANOTAÇÕES
GraphQL II
Consultas e Mutações: Fragmentos
Obs.: O fragmento é uma unidade reutilizável.
Os fragmentos permitem a construção de conjuntos de campos e incluem na consulta

onde for necessário.
Como apresentado na imagem acima, a consulta de “nome” e “friends” é um conjunto
de campos, ou seja, uma parte de uma query/fragmento, formados pela desestruturação da
anotação do Javascript “... comparisonFields”.
ANOTAÇÕES
GraphQL II
Obs.: O fragmento é o trecho de uma query que pode ser salva e reutilizada em outros
locais, sem ter a necessidade de repetir os elementos.
10m
Obs.: É possível nomear as querys apresentadas na imagem acima, acrescentando alguns

parâmetros como: variáveis de consulta.
Na imagem apresentada, foi criada a query com o nome “herocomparison”. No fragmento

“comparisonFields” será utilizado o parâmetro “friendsConnection”.
A variável “$first” foi definida com o número 3, logo, será apresentado os 3 primeiros
“friends”.
O front-end consegue realizar consultas melhores, enquanto o back-end irá responder de
forma diferente.
ANOTAÇÕES
GraphQL II
Consultas e Mutações: Nome da Operação
Obs.: O nome da operação é utilizado para deixar o código menos ambíguo.
O GraphQL recomenda que seja colocado o nome da operação.

Ex.: Query HeroNaneAndFriends.
O nome da operação irá servir para várias operações, principalmente a de log.
Obs.: Caso seja colocado o nome da operação, será necessário descrever o seu tipo.
Percebe-se que a resposta não foi alterada.
Consultas e Mutações: Variáveis
Obs.: Na maioria dos aplicativos, os argumentos dos campos podem ser dinâmicos.
15m
Ex.: Pode apresentar uma lista que permite selecionar em qual episódio o indivíduo está
interessado e um campo de pesquisa com um conjunto de filtros.
GraphQL II
Obs.: Será feita uma substituição do valor e irá permitir que a query seja ajustada na medi-
da de sua necessidade.
Considera-se importante a indicação dos argumentos que serão passados e definidos

para que a função possa operar corretamente.
Consultas e Mutações: Variáveis Padrão
Obs.: Caso a função seja chamada sem nenhum valor, será assumido um valor padrão.
Consultas e Mutações: Diretivas
Obs.: As diretivas permitem a colocação de uma condicional.
Ex.: friends @include(if: $withFriends)

ANOTAÇÕES
GraphQL II
• @include(if: Boolean) Apenas inclua este campo no resultado se o argumento for true;
• @skip(if: Boolean) Ignore este campo se o argumento for true;
Consultas e Mutações: Mutações
No Rest, será utilizado o método post que irá persistir um dado. Geralmente, não se reco-
menda que seja realizado um ged para alteração de dados.
20m
No GraphQL, qualquer consulta pode ser implementada para causar uma grava-
ção de dados.
Todas as operações que causam gravações devem ser declaradas explicitamente como
uma mutação.
Obs.: Quando estiver disposto “mutation”, haverá uma alteração no banco de dados ou
mecanismo de persistência que estiver sendo utilizado.
GraphQL II
Conforme na imagem acima, “estars” e “commentary” correspondem ao retorno.

As variáveis passadas correspondem ao upload para gerar uma persistência na base.
Obs.: O GraphQL é mais voltado para as consultas, no entanto, também permite realizar
as mutações.
Consultas e Mutações: Fragmentos em Linha
Obs.: Assim como outros esquemas de tipos, os esquemas do GraphQL incluem a capaci-
dade de definir interfaces e tipos de união.
Caso a consulta for realizada em um campo que retorne uma interface ou um tipo união,
irá precisar usar o fragmento para acessar dados do tipo concreto.
25m
ANOTAÇÕES
GraphQL II
Ex.: Conforme está apresentado na imagem acima, a pesquisa do tipo “an” busca todos
os resultados “an”.
EXERCÍCIOS DE FIXAÇÃO
1. (2018/CESPE/CEBRASPE/STM/Analista Judiciário/Análise de Sistemas) Em relação
ao desenvolvimento de aplicativos, julgue o seguinte item.
A linguagem GraphQL é utilizada para consulta a objetos gráficos em bancos de dados
relacionais.
( ) Certo
( ) Errado
COMENTÁRIO
O “Graph” corresponde à relação direcional entre eles e não de objetos gráficos de imagem.
O GraphQL não se limita aos bancos de dados relacionais, podendo ser utilizado também
no banco de dados não relacionais.
GABARITO
1. E
�Este material foi elaborado pela equipe pedagógica do Gran Concursos, de acordo com a aula pre-
parada e ministrada pelo professor Tiago Lage Payne de Pádua.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Domain Driven Design
DOMAIN DRIVEN DESIGN
Referências
Introdução
Domain Driven Design (DDD) é uma abordagem para o desenvolvimento de software

complexo (como um e-commerce) no qual:
• Foca-se no domínio principal;

– Trata-se do domínio do problema. Não se foca em tecnologia nem em hierarquia
de classes.
• Exploram-se modelos em uma colaboração criativa de profissionais de domínio e pro-

fissionais de software;
5m
– Não se trata de uma estrutura rígida, mas de uma perspectiva mais dinâmica.
– Colaboração mais significativa entre profissionais de arquitetura e de implementação.
• Fala-se uma linguagem onipresente dentro de um contexto explicitamente limitado.

ANOTAÇÕES
DESENVOLVIMENTO WEB
– Onipresente no sentido de abranger todos os segmentos. Por exemplo, em um

banco, as pessoas do atendimento podem se referir ao processo “abertura de conta”,
enquanto o desenvolvedor pode se referir ao mesmo processo como “transação
XK3”, ou seja, as linguagens não se conversam, é uma linguagem quebrada.
Muitos projetos realizam trabalhos de modelagem sem obter muitos benefícios reais no
final. Os padrões do DDD reúnem práticas bem-sucedidas de projetos em que há reais bene-
fícios na modelagem. O DDD não irá propor algo inteiramente novo, mas boas práticas já
reconhecidas.
Juntos, eles estabelecem uma abordagem bastante diferente para modelagem e desen-
volvimento de software, que vai de detalhes finos a visão de alto nível.
As convenções rigorosas de modelagem devem ser equilibradas com a exploração livre
de modelos em colaboração com pessoas não técnicas.
Táticas e estratégia devem ser combinadas para ter sucesso, e o DDD trata do design
tático e do estratégico. O design tático é o mais próximo da linha de código, mais refinado,
enquanto o design estratégico é mais de alto nível, de comunicação entre sistemas.
10m
Domínio
Domínio é a realidade em que habitamos: suas entidades, seu comportamento, leis a

que obedecem.
Ele existia antes de nós e existirá depois de nós, de uma forma ou de outra.
Sua existência não depende da nossa consciência, como um sistema de e-commerce.
Os profissionais de marketing criam novos recursos e realizam análises de mercado, os
principais gerentes de contas se comunicam com os clientes, os desenvolvedores de sof-
tware automatizam os processos de negócios.
É por isso que o domínio é chamado de espaço de Problema. No caso do e-commerce,
tanto o desenvolvedor quanto o pessoal do marketing vão entender do que se trata.
Contexto Limitado
Vários modelos estão em jogo em qualquer projeto grande. Eles surgem por muitas razões.
Dois subsistemas geralmente atendem comunidades de usuários muito diferentes, com
trabalhos diferentes, onde modelos diferentes podem ser úteis.
ANOTAÇÕES
DESENVOLVIMENTO WEB
As equipes que trabalham independentemente podem resolver o mesmo problema de

maneiras diferentes, devido à falta de comunicação.
O conjunto de ferramentas também pode ser diferente, significando que o código do pro-
grama não pode ser compartilhado.
A comunicação entre os membros da equipe fica confusa. Muitas vezes, não está claro
em que contexto um modelo não deve ser aplicado. Expressões de modelo, como qualquer
outra frase, só têm significado no contexto.
“Cliente”, por exemplo, pode não significar a mesma coisa se houver contextos limitados
diferentes. Por exemplo, se um funcionário de um banco abre um chamado para consertar
seu computador, ele será o cliente do chamado; por outro lado, se alguém abre uma conta
nesse banco, ele será cliente do banco.
Por essa razão, deve-se definir explicitamente o contexto no qual um modelo se aplica.
Define-se explicitamente limites em termos de organização da equipe, uso em partes espe-
cíficas do aplicativo e manifestações físicas, como bases de código e esquemas de banco
de dados.
15m
Deve-se aplicar a integração contínua para manter os conceitos e termos do modelo
estritamente consistentes dentro desses limites. Padroniza-se um único processo de desen-
volvimento dentro do contexto, que não precisa ser usado em outro lugar. Integração con-
tínua diz respeito ao fato de que a todo momento está sendo enviado um código para uma
base de códigos central e o código está sendo integrado, testado etc.
A figura a seguir ilustra uma situação de contextos limitados, “sales context” e “supor
context”. Observe que em ambos os contextos, há termos iguais, como “produto” e “cliente”.
Esses termos devem ser especificados quanto aos contextos a que pertencem.
DESENVOLVIMENTO WEB
Linguagem Onipresente
Consiste principalmente em usar o vocabulário de um determinado domínio comercial,

não apenas nas discussões sobre os requisitos de um produto de software, mas nas discus-
sões de design e até o “código-fonte do produto”.
Um dos problemas que muitos esforços de desenvolvimento de software enfrentam é
o atrito constante introduzido pela tradução entre dois vocabulários técnicos, o do domínio
comercial, por um lado, e o dos desenvolvedores, por outro. Um chamado de um profissional
da área comercial para o problema de “abertura de conta”, por exemplo, pode levar bastante
tempo para ser compreendido pelos desenvolvedores.
20m
Até certo ponto, essa dualidade é inevitável: os desenvolvedores devem estruturar seu
trabalho em termos de algoritmos e computação, que geralmente não têm equivalente direto
no vocabulário comercial.
No entanto, o vocabulário técnico costuma tender a “vazar” de limites razoáveis e assu-
mir as conversas de design até o ponto em que os especialistas em negócios começam a se
sentir alienados e a se desvincular de conversas cruciais.
A adoção deliberada e explícita de uma política de “linguagem onipresente” atenua essas
dificuldades.
Integração Contínua
Depois que um contexto delimitado é definido, devemos mantê-lo correto, isto é, garantir
que ele não se deteriore ao longo do tempo.
Quando várias pessoas estão trabalhando no mesmo contexto limitado, há uma forte ten-
dência para o modelo se fragmentar.
Quanto maior a equipe, maior o problema, mas apenas poucas pessoas podem encontrar
problemas sérios.
No entanto, dividir o sistema em contextos cada vez menores acaba perdendo um nível
valioso de integração e coerência.
Portanto, instale um processo de mesclagem de todos os códigos e outros artefatos de
implementação com frequência, com testes automatizados para sinalizar a fragmentação
rapidamente.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Exercite incansavelmente a linguagem onipresente para elaborar uma visão comparti-

lhada do modelo à medida que os conceitos evoluem na cabeça de diferentes pessoas. O
objetivo é incluir o máximo de pessoas possível, fazendo com que todos sejam responsáveis
por tudo, inclusive pelo modelo.
Model-Driven Design
Relacionar firmemente o código a um modelo subjacente dá significado ao código e torna

o modelo relevante.
Se o design, ou alguma parte central dele, não for mapeado para o modelo de domínio,
esse modelo terá pouco valor e a correção do software será suspeita.
Ao mesmo tempo, mapeamentos complexos entre modelos e funções de design são difí-
ceis de entender e, na prática, impossíveis de manter à medida que o design muda.
Uma divisão se abre entre a análise e o design, para que o insight obtido em cada uma
dessas atividades não se alimente da outra.
25m
Desenhe no modelo a terminologia usada no design e a atribuição básica de respon-
sabilidades.
O código se torna uma expressão do modelo, portanto, uma alteração no código pode ser
uma alteração no modelo. Assim, o autor recomenda que, se o código estiver se desvincu-
lando do modelo, não se deve fixar o código, mas atualizar o modelo – tanto o modelo pode
ser atualizado e refletir uma atualização no código quanto o contrário.
Seu efeito deve repercutir nas demais atividades do respectivo projeto.
Amarrar a implementação servilmente a um modelo geralmente requer ferramentas e lin-
guagens de desenvolvimento de software que suportem um paradigma de modelagem, como
programação orientada a objetos.
Portanto, projete uma parte do sistema de software para refletir o modelo de domínio de
uma maneira muito literal, para que o mapeamento seja óbvio.
Revise o modelo e modifique-o para ser implementado de forma mais natural no sof-
tware, mesmo que você tente fazê-lo refletir uma visão mais profunda do domínio.
Exija um modelo único que atenda bem a ambos os propósitos, além de oferecer suporte
a uma linguagem ubíqua fluente. Trata-se de fazer com que o modelo respeite o código e que
o código respeite o modelo.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Hands-on Modelers
Se as pessoas que escrevem o código não se sentem responsáveis pelo modelo ou não
entendem como fazer o modelo funcionar para um aplicativo, o modelo não terá relação com
o software.
Se os desenvolvedores não perceberem que a alteração do código altera o modelo, sua
refatoração enfraquece o modelo, em vez de fortalecê-lo, ou seja, o código ficará cada vez
mais longe do modelo.
Enquanto isso, quando um modelador é separado do processo de implementação, ele ou
ela nunca adquire, ou perde rapidamente, uma sensação das restrições da implementação.
A restrição básica do design orientado a modelo – que o modelo suporta uma implemen-
tação efetiva e abstrai as principais informações sobre o domínio – foi reduzida pela metade
e os modelos resultantes serão impraticáveis.
Finalmente, o conhecimento e as habilidades de designers experientes não serão trans-
feridos para outros desenvolvedores se a divisão do trabalho impedir o tipo de colaboração
que transmite as sutilezas de codificar um design orientado a modelos.
Portanto, qualquer pessoa técnica que contribui para o modelo deve passar algum tempo
tocando no código, seja qual for o papel principal que ele ou ela desempenhe no projeto. O
autor defende que quem faz a modelagem tenha também conhecimento de código e que
quem codifica tenha também conhecimento de modelagem.
DIRETO DO CONCURSO
1. (2015/CESPE/STJ/Técnico Judiciário/Tecnologia da Informação) Acerca de arquitetura
de software e Domain-Driven Design, julgue o seguinte item.
Domain-Driven Design pode ser aplicada ao processo de concepção arquitetural de um
sistema de software, sendo que domain, em um software, designa o campo de ação,
conhecimento e influência.
30m
2. (2019/CESPE/SLU-DF/Analista de Gestão de Resíduos Sólidos/Informática) Julgue o

próximo item, a respeito de domain-driven design, design patterns, emergent design,
enterprise content management e REST.
ANOTAÇÕES
DESENVOLVIMENTO WEB
No desenvolvimento embasado em domain-driven design, a definição da tecnologia a

ser utilizada tem importância secundária no projeto.
COMENTÁRIO
O foco é no problema, não na tecnologia.
GABARITO
1. C
2. C
A presente degravação tem como objetivo auxiliar no acompanhamento e na revisão do conte-
údo ministrado na videoaula. Não recomendamos a substituição do estudo em vídeo pela leitura
ANOTAÇÕES
DESENVOLVIMENTO DE SISTEMAS
Arquitetura Hexagonal
ARQUITETURA HEXAGONAL
A arquitetura hexagonal é um modelo estrutural de desenvolvimento de software que

se diferencia do modelo com aplicação de três camadas, MVC, em que existem camadas
definidas.
Em 2015, o engenheiro Alistair Cockburn escreveu um artigo sobre um outro modelo, o
hexagonal, com o objetivo de isolar a regra de negócios.
Obs.: o professor Tiago recomenda a leitura do artigo presente no seguinte endereço ele-
trônico: https://alistair.cockburn.us/hexagonal-architecture/
A arquitetura hexagonal, também chamada de arquitetura de portas e adaptadores é uti-

lizada em projetos de software, como padrão estrutural na construção de software. Visa a
criação de componentes de aplicação fracamente acoplados e de alta coesão, que podem
ser facilmente acoplados em um ambiente de software por meio das portas e adaptadores,
o que torna esses componentes intercambiáveis em qualquer nível e facilitam a automação
ANOTAÇÕES
e testes que estão interligados, uma vez que para testar é necessário automatizar a edição
do software.
Objetivo: permitir que um aplicativo seja conduzido igualmente por usuários, programas,
testes automatizados ou scripts em lote, seja desenvolvido e testado isoladamente de seus
eventuais dispositivos de tempo de execução e bancos de dados.
Existem comunicações no hexágono e em seu interior o core business se comunica tanto
com a base de dados quanto pela interface do usuário, com a ideia de que esse software
possa funcionar como agnóstico em relação a troca de portas.
5m
• Quando qualquer driver deseja usar o aplicativo em uma porta, envia uma solicita-
ção que é convertida por um adaptador para a tecnologia específica do driver em
uma chamada ou mensagem de procedimento utilizável, que passará para a porta do
aplicativo.
Obs.: driver é quem conduz o software, por exemplo, um usuário, um teste automatizado
ou um script em lote.
• O aplicativo desconhece a tecnologia do driver;

• Quando o aplicativo tem algo para enviar, o envia através de uma porta para um adap-
tador, que cria os sinais apropriados necessários para a tecnologia receptora (humana
ou automatizada);
• O aplicativo tem uma interação semanticamente sólida com os adaptadores em todos
os lados, sem realmente conhecer a natureza das coisas do outro lado dos adaptadores.
A aplicação (Application) é o core business, a lógica de negócio, que na figura abaixo

encontra-se isolada. Possui adaptadores tanto para os estímulos de entrada que pode ser o
chamado de uma outra aplicação, de um usuário, um sistema em lote etc. Os adaptadores
converteram esses estímulos de forma que cheguem uniformemente até a porta da aplica-
ção, que processará a regra de negócio e poderá fazer uma persistência, por exemplo, em
um banco de dados ou é possível, ainda, realizar a troca do adaptador, realizar uma persis-
tência em uma memória, se estiver rodando testes.
ANOTAÇÕES
A arquitetura hexagonal dividirá o sistema em vários componentes intercambiáveis por

serem fracamente acoplados e por existir uma camada de adaptador entre o núcleo da apli-
cação e os componentes externos que permitem essa troca.
Essa abordagem é uma alternativa à estrutura tradicional em camadas onde cada com-
ponente é conectado a outro por meio de portas expostas. A comunicação através das portas
segue um determinado protocolo a depender da sua finalidade, como, por exemplo, é possí-
vel receber uma comunicação via HTTP ou uma interação diretamente do mouse do usuário
se for uma interface gráfica.
Essas portas e protocolos definirão uma API abstrata que pode ser implantada por qual-
quer meio técnico. A título de exemplo, uma aplicação mobile se comunica com o servidor
através de uma API como ocorre em uma aplicação web, o que é muito utilizado atualmente.
A granularidade das portas são números não restritos, o hexagonal não tem relação
direta com o número, é apenas ilustrativo, podem existir mais ou menos portas.
10m
Os adaptadores são uma espécie de cola entre o mundo exterior e aplicação de negócio,
mediando a troca entre o mundo externo e as portas que representam os requisitos do com-
ponente interno do aplicativo. Pode haver vários adaptadores para cada porta, por exemplo,
se os dados puderem ser fornecidos pelo usuário por meio de uma interface gráfica, linha de
comando, aplicativo de celular ou qualquer outro.
Já na figura abaixo há a especificação de cada porta em que os termos “persistance”,

“notification”, “business eventes” e “administration” representam saídas.
ANOTAÇÕES
Motivação
• Um dos grandes bugs dos aplicativos de software ao longo dos anos tem sido a infil-
tração da lógica de negócios no código da interface do usuário;
O que acontece muitas vezes é que a lógica da aplicação acaba infiltrando na interface,
vazando. Por exemplo, utilizando a imagem acima como ilustração e a seguinte situação: ao
abrir uma conta bancária por meio de aplicativo a regra é que deve ser maior de 18 anos,
ao inserir essa informação na UI, no controle de tela para que não apareça mensagem se o
usuário for maior de 18 ano, ocorre uma infiltração na regra de negócios, na interface e, se
houver uma outra API se comunicando diretamente, essa restrição sobre maior de 18 anos
não aparecerá por não estar na aplication core, mas na interface. O correto seria que essa
regra estivesse no aplication core.
Ao vazar a lógica, gera uma série de problemas, o sistema não poderá ser testado com
perfeição pois existe lógica que não está inserida no core. Assim, no momento que o teste
for interagir com o core pela ausência da lógica, acarretará um problema. Pela mesma razão
é possível mudar o uso do sistema que pode ser dirigido por ação humana para um sis-
tema executado em lote. Utilizando o mesmo exemplo da abertura de conta, que ocorre pela
interface ou pelo sistema em lote por meio de um formulário, como não é possível executar
por meio da interface, segue direto via arquivo, a regra de negócios não será obedecida,
o que gera um problema, já que a regra de negócios ficou apenas na interface, bem como
ANOTAÇÕES
torna impossível permitir que o programa seja conduzido por outro, ou através de uma API,
integração.
Dessa forma, as empresas tentavam criar uma nova camada de arquitetura com a pro-
messa que nenhum malote de negócio escaparia da nova camada. Entretanto, não há nenhum
mecanismo que possa comprovar que mesmo diante da criação de novas camadas, o modelo
MVC, não poderia vazar também, é um problema que sempre acabava reaparecendo.
A ideia é exatamente bloquear para que a regra de negócio fique perfeita, para que no
momento da automatização, execução e processamento do software, interação de uma apli-
cação com outra, independentemente da interface a ser utilizada, a regra de negócio a ser
trabalhada será a mesma.
Natureza da Solução
• Tanto os problemas do lado do usuário quanto do lado do servidor são causados pelo
mesmo erro de design e programação — o emaranhamento entre a lógica de negócios
e a interação com entidades externas;
15m
Em um modelo de camadas, se houver o vazamento tanto para o lado da interface como

para quaisquer lados das camadas será ruim, pois ao rodar os testes não será possível utili-
zar a mesma base de dados e o teste não será completo.
• O hexágono destina-se a destacar visualmente:

a) A assimetria de dentro para fora e a natureza semelhante das portas;
b) A presença de um número definido de portas diferentes: duas, três ou quatro;
Diferentemente do modelo em camadas em que não era percebida uma simetria, como
no modelo hexagonal.
No modelo em camadas, o vazamento da regra de negócio para quaisquer lados, tanto
para cima, quanto para baixo era considerado ofensivo. Já no modelo hexagonal demons-
tra que qualquer dos elementos externos à aplicação são tão ofensivos quanto, em relação
ao vazamento da regra de negócio. O hexágono é mais uma representação visual no sen-
tido de demonstrar a existência de várias portas de comunicação, do que a literalidade dos
seis lados.
ANOTAÇÕES
Geralmente existem vários adaptadores para qualquer porta e várias tecnologias que
podem ser conectadas a ela. Pode ser diretamente interface, pode ser uma comunicação
web, entre outros nesse sentido.
Estrutura
A imagem abaixo demonstra uma conexão HTTP, há duas portas API (do usuário e de
dados) que podem ter vários adaptadores. Supondo que o API do usuário seja um CRUD de
usuário, poderá utilizar por meio uma interface gráfica, de uma aplicação para outra aplica-
ção, por várias formas. As duas portas API estão do lado do controle de aplicativo e do lado
da recuperação de dados.
O desenho demonstra que o aplicativo pode ser conduzido igualmente por um conjunto
de testes, independentemente da forma como for nomeada, a aplicação terá o mesmo resul-
tado porque está tudo inserido no core da aplicação.
O mapeamento da imagem abaixo é mais parecido com o modelo em camadas e demons-

tra, por meio das setas numeradas, a ordem em que uma equipe ou que aplicativo pode ser
utilizado. Por exemplo, o item número um, mostra que o aplicativo pode ser conduzido por
meio de um teste que se comunicará com um banco de dados “mockado”. E o item dois uma
interface do usuário com um banco de dados “mockada”, bem como pode ser um banco de
dados real de ambiente de desenvolvimento.
ANOTAÇÕES
As chamadas realizadas pela aplicação ao banco de dados são independentes, pois,

segundo a imagem, enquanto o teste roda, não há informação de que o banco de dados está
sendo acessado, seja ele “mockado” ou real. A forma de realização da chamada é a mesma,
existe um fraco acoplamento nessa questão. No item 4, a interface do usuário, pode acessar
diretamente o banco de dados que é o mais usual no cotidiano dessa aplicação.
20m
Assim, basicamente o que o modelo hexagonal demonstra que há o isolamento do núcleo

da aplicação, possui um modelo de portas que são as API’s, as funcionalidades da aplica-
ção e os adaptadores que são formas diferentes de comunicação com a porta. Dessa forma,
existe um acoplamento muito fraco em que é possível a troca entre os adaptadores tanto de
um lado quanto do outro, sem que nenhuma delas saiba que foi atingida ou que a aquela
parte possua um conhecimento interno da aplicação para executar um comando diferente.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
MICROSSERVIÇOS
Esta aula é sobre microsserviços. Esse é um assunto muito atual e está em voga por ser
muito utilizado por empresas, como Amazon, Google e Netflix. O microsserviço é uma boa
estratégia para escalar produtos e serviços. As empresas brasileiras começaram a intensifi-
car a sua utilização nos últimos anos e as estatais também, por isso este assunto tem sido
cobrado em provas.
Referências Bibliográficas
Em geral, não há uma literatura acadêmica vasta sobre este assunto, mas há bastante
conteúdo na internet. Recomenda-se que busquem autores ou sites que sejam referên-
cia na área.
– https://www.martinfowler.com/articles/microservices.html
– https://azure.microsoft.com/pt-br/blog/microservices-anapplication-revolution-powe-
red-by-the-cloud/
– https://microservices.io/
– https://www.redhat.com/pt-br/topics/microservices
Obs.: o que mais se aproxima de uma discussão mais completa é o artigo do Martins
Fowler, que é uma referência no mercado.
Introdução
• O termo “Arquitetura de Microsserviços” surgiu nos últimos anos para descre-
ver uma maneira particular de projetar aplicativos de software como conjuntos
de serviços de implantação independente;
5m
• Embora não haja uma definição precisa desse estilo de arquitetura, há certas carac-
terísticas comuns em torno da organização em relação à capacidade comercial, à
implantação automatizada, à inteligência nos endpoints e ao controle descentralizado
de linguagem e dados;
Isto é, não tem uma definição precisa ou uma especificação formal. Existe uma série de
conceitos comuns que vão formar o microsserviço.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
Exemplo: em um grande banco tem um conjunto muito grande de softwares como:

seguro, previdência, abertura de contas, fazer boletos, dentre outros. Uma estratégia seria
transformar tudo em um software executável e outra estratégia seria ter vários sistemas inde-
pendentes: um para previdência, um para abertura de contas e etc. Na verdade, quando se
trabalha em microsserviço, cada um dos sistemas terá ainda mais divisões.
Sobre microsserviço é preciso ter bastante claro que ele é a divisão de um serviço maior
em serviços pequenos.
Introdução
• O estilo arquitetural de microsserviço é uma abordagem para desenvolver um
único aplicativo como um conjunto de pequenos serviços, cada um executando
em seu próprio processo e comunicando-se com mecanismos leves, geralmente
uma API HTTP;
Exemplo: para abertura de uma conta é preciso fazer o cadastro do cliente e fazer algu-
mas consultas no Serasa e SPC, além de fazer a própria abertura da conta. Perceba que
cada um desses passos são pequenos serviços.
Em vez de ter um grande programa, como banco.exe, há vários sistemas pequenos que
vão se comunicar por meio de uma API de comunicação entre os serviços, sendo que eles
podem estar em diferentes máquinas ou em diferentes partes da rede. Em geral, eles vão se
comunicar na rede por meio de uma API HTTP, que é um protocolo para transmitir dados, e
uma API REST, em um nível mais alto, para transmitir esses dados e conversar entre essas
aplicações.
• Esses serviços são criados com base nos requisitos de negócio e implementados de
maneira independente por um mecanismo de implantação totalmente automatizado;
10m
Obs.: um serviço pode ser retirado do ar e colocado novamente sem que se tenha que tirar
todo o sistema do ar.
• Há um mínimo de gerenciamento centralizado desses serviços, que pode ser

escrito em diferentes linguagens de programação e usar diferentes tecnologias
de armazenamento de dados;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
Uma das premissas é que é possível ter uma certa arquitetura organizacional desse
microsserviço, um certo tipo de controle desse microsserviço, mas é possível ser implemen-
tado em diferentes tecnologias, inclusive banco de dados diferentes.
Por exemplo, um microsserviço em Node, outro em Python, outro em Java eles se comu-
nicam através de uma API REST sem problemas. É possível ter banco de dados diferentes
um em SQL, outro em UDB.
A tecnologia anterior:
Monolito
Obs.: ideia de uma peça única e grande.
• No estilo monolítico, um aplicativo é construído como uma única unidade. Os

aplicativos corporativos geralmente são construídos em três partes principais: uma
interface de usuário do lado do cliente (páginas HTML e JavaScript) um banco de
dados e uma aplicação do lado do servidor.
• O aplicativo do lado do servidor manipulará solicitações HTTP, executará a lógica
do domínio, recuperará e atualizará dados do banco de dados e selecionará e
preencherá as exibições HTML para serem enviadas ao navegador.
Obs.: solicitações HTTP são do servidor.
Por exemplo, um Front-end com HTML e CSS e Javascript vai se comunicar com o Back-
-end (que pode ser em Java) e esse Back-end por sua vez vai se comunicar com a Database.
No Back-end, em geral, ficam as regras de negócios, segurança.
• Este aplicativo do lado do servidor é um monolito - um único executável lógico. Quais-
quer alterações no sistema envolvem a criação e a implantação de uma nova versão
do aplicativo do lado do servidor;
Por exemplo, no sistema chamado banco.exe, toda vez que é feita alguma alteração, tem
que desinstalar todo o sistema e implantá-lo. Atualmente, com o uso de mais recursos, os
softwares começaram a ficar muito grandes e esse estilo de trabalho com o monólito acabou
ficando um pouco defasado, pois traz problemas no desenvolvimento.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
Monolito - Problemas
• Aplicativos monolíticos podem ser bem-sucedidos, mas cada vez mais as pessoas
estão sentindo frustrações com elas - especialmente à medida que mais aplica-
tivos são implantados na nuvem.
15m
• Os ciclos de mudança ficam amarradas - uma alteração feita em uma pequena parte
do aplicativo requer que todo o monolito seja reconstruído e implantado.
Exemplo: o grande aplicativo banco.exe, se está fazendo um ajuste na parte de capita-
lização, por causa desse ajuste, terá que versionar todo o sistema do banco e implantá-lo
inteiramente. Este é um problema.
Outro problema seria:
• Ao longo do tempo, muitas vezes é difícil manter uma boa estrutura modular, tor-
nando mais difícil manter as alterações que devem afetar apenas um módulo dentro
desse módulo. Caso necessário, deve-se escalar todo o aplicativo, em vez de partes
dele que exigem maior recurso.
A primeira parte é a relação da divisão do software, a outra parte citada é em relação
de escala.
Exemplo: o sistema banco.exe começa a ter muitos clientes consumindo a parte de pre-
vidência. A parte de previdência fica bastante exausta e começa a consumir recursos. Nesta
situação, o que deve ser feito é escalar esse sistema e montar um cluster de servidores.
Só que quando montar esse cluster será necessário replicar o sistema inteiro do banco em
cada um dos servidores porque não está dividido. Então, quando tem que escalar por uma
pequena parte do sistema, tem que escalar o sistema todo. No microsserviço, poderia ser
escalada somente a parte da previdência e consumir bem menos recursos.
Uma aplicação monolítica coloca todas suas funcionalidades em um único processo.
Obs.: Cada uma dessas formas é uma parte do sistema.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
E escala replicando o monolito em múltiplos servidores
Então, quando tem que escalar, ou seja, atender mais clientes, o que deve ser feito é
replicar, mas replicar o sistema como um todo, gastando bastante recursos para instalar.
Uma arquitetura de microsserviços coloca cada elemento de funcionalidade em um
serviço distinto...
Perceba que é como se tivesse vários sistemas menores, cada um está fazendo um pouco.
E escala distribuindo estes serviços entre servidores, replicando quando necessário.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
Por exemplo, o serviço bola está nas quatro máquinas, digamos que temos quatro instân-
cias dele. Alguns têm apenas três instâncias, outros apenas uma instância. Estamos esca-
lando de forma distinta.
À medida que vamos dividindo o sistema em microsserviço, conseguimos escalar no sen-
tido de colocar mais máquinas para executar aquele serviço, mas de uma maneira menor,
apenas para o microsserviço necessário.
Microsserviços
• Essas frustrações levaram ao estilo arquitetural de microsserviço: construir
aplicativos como conjuntos de serviços.
20m
• Além do fato de que os serviços são independentemente implantáveis e escaláveis, cada
serviço também fornece uma fronteira rígida entre os módulos, permitindo até mesmo
que diferentes serviços sejam escritos em diferentes linguagens de programação;
• Eles também podem ser gerenciados por equipes diferentes.
O primeiro ponto: quando falam que os serviços são independentes, escaláveis e implan-
táveis de forma independente, significa escalar, implantar e até tirar sem mexer no sistema
como um todo. Podemos escalar, colocar mais instâncias, mais cópias do serviço para ser
executado, para atender um número maior de clientes de uma forma independente, escalar
só o que está dando problema.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
Exemplo: temos um serviço para o cadastro, outro para previdência, outro para capita-
lização e eles estão separados. Se alterar algo na capitalização, não vai alterar o serviço de
previdência, pois estão separados devido a uma fronteira muito rígida (talvez até por lingua-
gem de programação) um pode estar em Node e outro em Java esses são os benefícios de
trabalhar dessa forma.
Características de uma arquitetura de microsserviço

• Não há uma definição formal do estilo arquitetural de microsserviços, mas pode-
mos descrever o que se vê como características comuns para arquiteturas que
se encaixam neste rótulo;
Não há uma definição formal e não há um programa que é o microsserviço:é um estilo
arquitetural, um conjunto de práticas, um estilo de desenvolvimento.
• Como acontece com qualquer definição que defina características comuns, nem todas
as arquiteturas de microsserviço possuem todas as características, mas espera-se
que a maioria das arquiteturas de microsserviço exiba a maioria das características;
Componentização via Serviços

Componentização é um termo antigo da indústria de software.
• Quando falamos de componentes, nos deparamos com a difícil definição do que faz
um componente. Uma definição é que um componente é uma unidade de software
que é independentemente substituível e atualizável.
• As arquiteturas de microsserviço utilizam bibliotecas, mas sua principal forma
de componentizar seu próprio software é dividindo-se em serviços.
As bibliotecas continuando sendo usadas como módulos. No entanto, o software é divi-
dido em pequenos serviços.
• Definimos bibliotecas como componentes vinculados a um programa e chamados atra-
vés de função na memória, enquanto os serviços são componentes fora do processo
que se comunicam com um mecanismo, como uma solicitação de serviço da Web ou
uma chamada de procedimento remoto;
25m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
Diferença entre biblioteca e serviço neste conceito: uma biblioteca é uma dependência do
projeto em que as funcionalidades da biblioteca são chamadas por meio de memória, porque
está integrado ali, faz parte do conjunto do software. E o microsserviço seria algo chamado
através de uma rede.
• Um dos principais motivos para usar os serviços como componentes (em vez de biblio-
tecas) é que os serviços são implantáveis de maneira independente;
Poderíamos dividir o software do sistema do banco e em vez de ser tudo no mesmo
executável, podemos ter uma biblioteca chamada capitalização, outra chamada previdência,
uma abertura de contas. Mas isso não seria microsserviço, porque a implantação final desse
sistema, isto é, a maneira como vamos colocar para rodar,é como um único monólito, apesar
de ter bibliotecas que dividem os módulos dos serviços, no final é um único monólito que
consome essa biblioteca, mas não está dividindo o microsserviço.
• Se você tiver um aplicativo que consista em várias bibliotecas em um único pro-
cesso, uma mudança em qualquer componente único resultará na necessidade
de reimplantar o aplicativo inteiro.
• Porém, se for decomposto em vários serviços, mudanças em um serviço exigem que
somente ele seja reimplantado. No entanto, algumas mudanças irão mudar as interfa-
ces de serviço resultando em alguma coordenação, mas o objetivo da arquitetura de
microsserviço é minimizá-las através de limites de serviço coesos e mecanismos de
evolução nos contratos de serviço.
• Porém há algumas desvantagens na utilização de serviços.
• As chamadas remotas são mais caras do que as chamadas em processo e, por-
tanto, as APIs remotas precisam ser menos granulares, o que geralmente as
torna mais complicadas de se utilizar.
As chamadas remotas são mais caras que as chamadas em processo, porque a cha-
mada em processo é uma chamada da memória do sistema. Um aplicativo chama o outro
através da memória, então é muito mais barato para executar. Ao passo que um microsser-
viço se comunica com outro através da rede e essa chamada é bem mais cara.
• Se for necessário alterar a alocação de responsabilidades entre os componentes,
esses movimentos de comportamento são mais difíceis de serem feitos quando se
está cruzando os limites do processo;
30m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços
Alterar a alocação de responsabilidades entre os componentes significa que o compo-

nente faz uma coisa e passará a fazer outra. Isso vai tornar o sistema difícil quando está
trabalhando com microsserviço, porque está tudo dividido. Toda vez que fizer uma altera-
ção, principalmente quando envolve a interface ou uma fronteira entre os microsserviços, as
coisas acabam ficando mais difíceis, isso é uma desvantagem. Se tivesse no monólito, essas
alterações seriam mais fáceis de fazer porque o sistema é único.
preparada e ministrada pelo professor Tiago Lage.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços II
MICROSSERVIÇOS II
ORGANIZADO EM TORNO DE RECURSOS DE NEGÓCIOS
A divisão em microsserviços deve levar em conta mais os termos de uma questão de

negócio do que uma questão técnica.
• Ao procurar dividir um grande aplicativo em partes, muitas vezes as gerências

se concentram nas camadas de tecnologias, criando as equipes de interface do
usuário, equipes de lógica do lado do servidor e equipes de banco de dados;
Uma visão tradicional, geralmente, divide as equipes em termos de recursos tecnológicos:

uma equipe de interface, equipe de lógica do servidor e equipe de banco de dados.
• Quando as equipes são separadas, até mesmo alterações simples podem levar a um
projeto de múltiplas equipes, que leva tempo e aprovação orçamentária;
Exemplo: no sistema de um banco, uma equipe cuida da interface, outra equipe da lógica
desse sistema e uma terceira equipe cuida do banco de dados. Perceba que toda vez que
se fizer uma alteração, como uma nova tela no sistema de abertura de contas, envolverá as
três equipes, tal modelo que pode ser caro em termos burocráticos e em termos de negócio
da instituição.
• Qualquer organização que projete um sistema (definido de maneira ampla) produzirá

um design cuja estrutura é uma cópia da estrutura de comunicação da organização -
Melvyn Conway, 1967
Obs.: O sistema reflete a própria hierarquia da empresa. Se a empresa tem uma hierarquia,
uma divisão, o software reflete a mesma divisão.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços II
Nesse modelo de times divididos funcionalmente, as equipes estão divididas por

funcionalidades, que trabalham técnicas DBAs, e não por negócio. Isso vai fazer com que a
arquitetura tenha a mesma divisão, tendo um projeto de front end, um projeto de back end
de especialista em servidores e projeto para banco de dados, as mesmas divisões que a
empresa tem, refletem no sistema.
Um aspecto negativo disso, é que o sistema fica bastante dividido em termos de equipes
e toda vez que tem que mexer em uma pequena parte do sistema, vai envolver várias equipes
diferentes.
5m
• A abordagem de microsserviços é diferente, dividindo-se em serviços organizados

em torno de funcionalidades de negócios;
• Esses serviços exigem uma implementação de software de grande espectro
para essa área de negócios, incluindo interface de usuário, armazenamento
persistente e qualquer colaboração externa;
Obs.: Equipe de caráter multidisciplinar.

ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços II
• Consequentemente, as equipes são multifuncionais, incluindo toda a gama de

habilidades necessárias para o desenvolvimento: experiência do usuário, banco de
dados e gerenciamento de projetos;
Digamos que o sistema é dividido por funcionalidade de negócios, quando tem que fazer
uma intervenção em uma parte do sistema, é possível fazê-la de uma forma mais rápida, pois
todas as equipes estão reunidas.
Um exemplo pode ser visto na imagem abaixo:
Vários times multidisciplinares vão entregar uma parte do sistema, um microsserviço, o

qual é desenvolvido mais rapidamente. O principal ponto é que os times são multifuncionais
e em um time há várias equipes de conhecimentos diferentes.
• Monolitos também podem ser modularizados em torno de funcionalidades de

negócios, embora esse não seja o caso comum;
Aplicar essa estratégia no monólito, pode gerar alguns problemas. O fato de ele ser
monolítico, isto é, o aplicativo ficar todo junto, fazer essa divisão dos times é bem mais difícil.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços II
• A principal dificuldade é que eles tendem a se organizar em muitos contextos.

Se o monolito se estender por muitos desses limites modulares, pode ser difícil
para os membros individuais de uma equipe encaixá-los em sua memória de
curto prazo;
O monólito não tem uma fronteira muito rígida entre os módulos e os contextos.
• Além disso, vemos que as fronteiras modulares exigem muita disciplina para
serem aplicadas. A separação necessariamente mais explícita exigida pelos
componentes de serviço facilita a manutenção dos limites da equipe;
Fazer isso no monólito apesar de ser possível, na prática, é difícil. Ao contrário do

microsserviço que acaba fazendo que isso ocorra naturalmente e tem a divisão mais fácil
dos times multidisciplinares.
PRODUTOS NÃO PROJETOS
• A maioria dos esforços de desenvolvimento de aplicativos usam um modelo de

projeto: onde o objetivo é entregar algum software que é considerado concluído.
Após a conclusão, o software é entregue a uma equipe de manutenção e a equipe
de projeto que a construiu é desfeita;
Em uma abordagem muito tradicional e monolítica, vamos ter uma equipe em

desenvolvimento e depois uma equipe em manutenção. Então, é feito o monólito e depois
ele é testado, em seguida coloca em produção e entrega para a equipe de manutenção. A
equipe que construiu poderá ser desfeita.
Outra abordagem é:
• Os defensores de microsserviços tendem a evitar esse modelo, preferindo a
noção de que uma equipe deve possuir um produto durante toda sua vida útil.
Uma inspiração comum para isso é a noção da Amazon de "você constrói, você o
executa", onde uma equipe de desenvolvimento assume total responsabilidade pelo
software em produção. Isso leva os desenvolvedores ao contato diário com o modo
como o software se comporta na produção e aumenta o contato com os usuários, já
que eles precisam assumir pelo menos parte da carga de suporte;
10m
DESENVOLVIMENTO WEB
Microsserviços II
Outra abordagem que acaba sendo muito utilizada no microsserviço é que depois de
construído, o software vai para manutenção e continuará sendo monitorado, isto é, o software
continua sendo responsabilidade da equipe que o construiu.
Essa é uma visão de produto e não projeto. No produto, a equipe é responsável pela
construção, implantação e manutenção.
• A mentalidade do produto está ligada às suas capacidades de negócios. Em vez

de considerar o software como um conjunto de funcionalidades a ser concluído,
há um relacionamento contínuo em que a questão é como o software pode ajudar
seus usuários a aprimorar a capacidade de negócios;
A visão é mais de negócio, de como o software vai produzir resultados e não apenas que
um projeto foi concluído.
• Não há razão para que essa mesma abordagem não possa ser usada com aplicativos
monolíticos, mas a menor granularidade dos serviços pode facilitar a criação de
relacionamentos pessoais entre os desenvolvedores de serviços e seus usuários;
Obs.: Microsserviço é um assunto relativamente novo e há poucas questões sobre esse

assunto.
DIRETO DO CONCURSO
1. (2018/CESPE/MPE-PI/ANALISTA MINISTERIAL/TECNOLOGIA DA INFORMAÇÃO)
Julgue o item a seguir, concernentes a microsserviços e arquiteturas de integração.
Um princípio básico dos microsserviços é que cada serviço gerencia seus próprios
dados, sendo responsável pelo armazenamento particular desses dados e também
pela execução em seus próprios processos.
COMENTÁRIO
O microsserviço vai trabalhar com os dados separados. Cada serviço vai ter uma base
de dados separada específica e não vai construir uma grande base de dados, como era o
monólito. No microsserviço, inclusive pode ter base de dados diferentes e também estar
executando o próprio processo.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços II
2. (2015/ CESPE/TRE-MT/ANALISTA JUDICIÁRIO/ANÁLISE DE SISTEMAS) No que se

refere à arquitetura de microsserviços, assinale a opção correta.
a. A arquitetura de microsserviços é similar à arquitetura monolítica, com relação à
quantidade de componentes e de módulos.
b. Apesar de essa arquitetura permitir a inserção de componentes de segurança e
autenticação nos serviços, a falha em um microsserviço compromete os demais.
c. Em decorrência de sua composição, sua coesão e seu acoplamento, somente pode
ser desenvolvida em linguagens a partir da 4.ª geração.
d. A arquitetura de microsserviços está relacionada à construção de sistemas distribuídos
formados por pequenos serviços coesos que são capazes de evoluir e podem até
mesmo ser completamente reescritos, ao longo da vida da aplicação.
e. Essa arquitetura está relacionada à criação de aplicações usando-se apenas um
módulo contendo a lógica e a persistência de dados.
COMENTÁRIO
a. A arquitetura de microsserviços não é similar à arquitetura monolítica em relação à
quantidade de componentes e de módulos.
b. É o contrário, a falha em microsserviço não compromete os demais, somente aquele
microsserviço.
c.Quando se trabalha com microsserviço é baixo acoplamento e alta coesão, mas não tem
restrição na linguagem de programação, podendo trabalhar em qualquer linguagem.
15m
d. O sistema será distribuído por pequenos serviços coesos, cada um faz algo que realmente
faz sentido.
e. São características do monólito.
Obs.: Pode-se perceber que a cobrança das bancas é com base em conceitos.
END-POINTS INTELIGENTES E CANAIS BURROS
• Ao construir estruturas de comunicação entre diferentes processos, existem

muitos produtos e abordagens que enfatizam a colocação de inteligência
significativa no próprio mecanismo de comunicação;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços II
• Um bom exemplo disso é o Enterprise Service Bus (ESB), que geralmente

incluem recursos sofisticados para roteamento de mensagens, coordenação,
transformação e aplicação de regras de negócios;
Imagine que se dividiu o sistema em vários microsserviços distintos e será necessário

um canal de comunicação entre eles. O microsserviço pressupõe que os end-point tenham
bastante inteligência e que o canal seja burro (no sentido de não ter uma lógica por dentro),
simplesmente serve como um canal de comunicação entre esses microsserviços. Existem
abordagens diferentes como usb, enterprise service bus em que pode ser colocada a lógica
de negócio no canal.
Exemplo: colocar no canal de comunicação um tipo de validação de segurança e não
no end-point. Neste caso estaríamos trazendo mais inteligência para o canal. O ideal na
arquitetura de microsserviço é que o canal seja o mais simples possível, que não tenha
inteligência.
• A comunidade de microsserviços prefere uma abordagem alternativa;

• Aplicações construídas a partir de microsserviços visam ser tão desacopladas
e tão coesas quanto possível - elas possuem sua própria lógica de domínio e
agem mais como filtros no sentido clássico do Unix - recebendo uma solicitação,
aplicando a lógica conforme apropriado e produzindo uma resposta;
• Estes são coordenados usando protocolos REST simples, em vez de protocolos
complexos ou orquestração por uma ferramenta central;
Ou seja, há uma alta coesão e baixo acoplamento quando se utiliza o microsserviço.

Uma comunicação via REST (que é protocolo HTTP), em geral, tem pouca ou nenhuma
inteligência no canal de comunicação.
• Outra abordagem comum é o envio de mensagens através de um barramento de

mensagens leve;
• A infraestrutura escolhida é tipicamente burra (burra pois atua apenas como um
roteador de mensagens) implementações simples como RabbitMQ ou ZeroMQ não
fazem muito mais do que fornecer um meio assíncrono confiável – a parte inteligente
ainda reside nos endpoints que estão produzindo e consumindo as mensagens, ou
seja, nos serviços;
20m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços II
Há dois tipos em geral de comunicação entre os microsserviços: API via REST, que é
uma comunicação síncrona, e uma comunicação utilizando uma MQ RabbitMQ ou ZeroMQ,
que é uma comunicação assíncrona.
• Em um monólito, os componentes estão sendo executados no processo e a

comunicação entre eles é via chamada de método ou chamada de função;
• O maior problema em transformar um monolito em microsserviços está em
mudar o padrão de comunicação. Uma conversão ingênua das chamadas do
método na memória para o RPC leva a comunicações que não funcionam bem;
• Em vez disso, é necessário substituir a comunicação refinada por uma abordagem
menos granular.
Exemplo: Um sistema com o monólito será migrado para uma série de microsserviços.
A forma mais ingênua de se fazer isso é simplesmente pegar as chamadas de função.
Não é uma abordagem muito boa, pois vai exigir uma comunicação muito intensa e é um
tráfego muito grande de rede, porque a comunicação não será mais em termos de memória
e sim em tráfego de rede, isso acaba tornando o sistema mais lento e a situação é piorada.
A argumentação é que tem de ser menos granular o serviço. Por isso essa divisão de
simplesmente pegar os módulos e transformá-los em microsserviço não é uma boa abordagem.
GABARITO
1. C
2. d
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
MICROSSERVIÇOS III
Governança Descentralizada
• Uma das consequências da governança centralizada é a tendência de padroni-
zar plataformas tecnológicas únicas. A experiência mostra que esta abordagem é
constritiva – nem todo problema é um prego, nem toda solução é um martelo.
É preferível usar a ferramenta certa para o trabalho certo e, embora os aplicativos
monolíticos possam tirar vantagem de diferentes linguagens até certo ponto,
isso não é comum.
Isso significa que quando estamos trabalhando com o monólito do sistema (banco.exe,
por exemplo, é um grande monólito que faz todas as funcionalidades do banco), estamos res-
tringindo todo mundo a trabalhar com a mesma tecnologia. Ao passo que, no microsserviço,
vamos para um modelo de governança descentralizada. Neste sentido, é possível trabalhar
com tecnologias diferentes para problemas diferentes.
Exemplo: A abertura de contas em linguagem Python, e, para previdência, o uso de

Node. Perceba que podemos dividir cada microsserviço e trabalhar com uma arquitetura de
software diferente, inclusive a linguagem de programação e armazenamento de dados.
• Dividindo os componentes do monólito em serviços, temos uma escolha ao cons-

truir cada um deles. Pode-se usar o Node.js para levantar uma página de relatórios
simples, C ++ para um componente particularmente elaborado em tempo real ou
outro tipo de banco de dados que melhor se adapte ao comportamento de leitura de
um componente.
O microsserviço é dividido em vários pequenos serviços e cada um pode ter uma pilha
tecnológica diferente que melhor se adapte àquele problema que se busca resolver.
Exemplo: Um microsserviço de revisão cadastral, que cuida do armazenamento. Inicial-

mente decide-se por usar um banco de dados relacional e posteriormente mudam para um
banco de dados não relacional. Se não mudar a interface de comunicação daquele serviço,
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
não terá impacto no resto do sistema, porque basicamente vai comunicar com o mesmo ser-
viço e ele vai devolver a mesma informação. Portanto, não vai alterar o resto do sistema, o
que é uma grande vantagem quando se está trabalhando com microsserviço.
Governança Descentralizada
• Claro, só porque você pode fazer alguma coisa, não significa que você deva - mas
particionar seu sistema com microsserviços significa que você tem a opção;
5m
Ou seja, não é o caso de fazer 30, 40 microsserviços e cada um com uma pilha tecno-
lógica diferente do outro. Pode até ser feito, mas não é o ideal, pois estará indo para outro
extremo, em que o custo de manutenção é bem mais difícil, pois a equipe deverá conhecer
várias tecnologias diferentes. Entretanto, quando é feito de forma consciente e controlada, é
bastante vantajoso.
• As equipes que criam microsserviços preferem uma abordagem avessa aos

padrões. Em vez de usar um conjunto de padrões definidos escritos em algum
lugar no papel, eles preferem a ideia de produzir ferramentas úteis que outros
desenvolvedores possam usar para resolver problemas semelhantes aos que
estão enfrentando.
A abordagem do microsserviço é muito pragmática em relação à tecnológica, em vez de

pegar algum padrão escrito para alguma empresa, muito específico para resolver alguma
situação ou um padrão mais teórico, as pessoas preferem resolver de forma prática. Um
tempo atrás era o contrário, tinha um foco muito grande em padrões formais, padrões buro-
cráticos, e por vezes muito longe da realidade do desenvolvimento.
• Essas ferramentas geralmente são coletadas de implementações e compartilha-

das com um grupo mais amplo, às vezes, mas não exclusivamente, usando um
modelo interno de código aberto.
Algumas empresas usam modelo de código aberto interno ou externo. Um exemplo é a

Netflix, que usa bastante microsserviço e essas ferramentas estão expostas para a comuni-
dade, para quem quiser usar de forma gratuita.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
Gerenciamento de Dados Descentralizado

• A descentralização do gerenciamento de dados se apresenta de várias maneiras
diferentes;
• No nível mais abstrato, significa que o modelo conceitual do mundo será diferente
entre os sistemas;
• Esse é um problema comum na integração em uma grande empresa, a visão de
vendas de um cliente será diferente da visão de suporte. Algumas coisas que são
chamadas de clientes na visão de vendas podem não aparecer na visão de suporte.
E os que se repetem podem ter diferentes atributos e (pior) atributos comuns com
semântica sutilmente diferente.
No sistema monolítico, todos acessando o mesmo banco de dados, isso forçava uma
visão homogênea de toda a empresa. Por exemplo, o suporte tem o conceito de “cliente”, ao
passo que o setor de vendas possui outro conceito de “cliente”, e quando fica tudo junto no
monólito, é muito complicado de fazer manutenção, porque mistura o código de uma equipe
com outra.
Quando estamos descentralizando isso, inclusive para os bancos de dados, favorecemos

que cada uma dessas equipes tenha uma visão diferente e possa colocar no seu sistema a
sua visão correta sem impactar na visão do outro sistema.
• Esse problema é comum entre aplicativos, mas também pode ocorrer dentro de
aplicativos, especialmente quando esse aplicativo é dividido em componentes
separados;
• Uma maneira útil de pensar sobre isso é a noção de Contexto Limitado do Design
Orientado a Domínio. O DDD (Domain Driven Design) divide um domínio complexo
em vários contextos limitados e mapeia as relações entre eles. Esse processo é útil
para arquiteturas monolíticas e de microsserviço, mas há uma correlação natural entre
limites de um microsserviço e um contexto que ajuda a esclarecer.
10m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
Hoje em dia já se pensa em dividir o sistema usando a técnica do DDD, não dividindo de
forma técnica, mas dividindo em termos de orientação de domínios de negócios, isto é, mar-
cando as fronteiras do sistema em relação aos domínios de negócios e não em relação aos
domínios de sistema, é isso que preconiza o DDD.
Também é possível usar essa técnica de DDD para o monólito, dividindo cada uma das
partes do sistema de acordo com o domínio de negócio que esteja atuando. No entanto,
quando fazemos isso com o microsserviço, é muito mais simples, porque em geral cada
domínio desse negócio vai ser seu próprio microsserviço.
Por exemplo, abertura de conta é um microsserviço, capitalização é outro microsserviço.

Ou seja, vai dividindo em partes de negócio o sistema e cada uma dessas partes de negócios
pode eventualmente se tornar um microsserviço distinto.
• Além de descentralizar decisões sobre modelos conceituais, os microsserviços

também descentralizam as decisões de armazenamento de dados.
O modelo do banco de dados pode ser diferente entre os microsserviços e a tecnologia

de armazenamento também.
• Embora os aplicativos monolíticos prefiram um único banco de dados lógico para

dados persistentes, as empresas geralmente preferem um único banco de dados
em vários aplicativos – muitas dessas decisões são conduzidas por meio de mode-
los comerciais do fornecedor em torno de licenciamentos.
Obs.: É uma prática muito comum. Até por questões de licenciamento e custos, é comum
que se tenha um único banco de dados no modelo monolítico.
• Os microsserviços preferem permitir que cada serviço gerencie seu próprio banco
de dados, sejam instâncias diferentes da mesma tecnologia de banco de dados
ou sistemas de banco de dados totalmente diferentes – uma abordagem chamada
Persistência Poliglota.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
Quando estamos no monólito, vamos preconizar a unidade do modelo de banco de dados

tanto pelo lado do modelo conceitual, quanto pelo lado tecnológico. E quando vamos para o
microsserviço, vamos para o oposto disso, podemos descentralizar tanto o modelo conceitual
dos dados, quanto o modelo tecnológico.
Na imagem, há dois momentos: no primeiro, há a representação de vários usuários aces-

sando o mesmo monólito e o monólito vai acessar uma base de dados única, grande e com
várias tabelas distintas. No segundo momento, é um modelo baseado em microsserviços,
cada um tem um banco de dados individual (mas pode também ter dois microsserviços que
consomem o mesmo bando de dados).
• Descentralizar a responsabilidade pelos dados em microsserviços tem implica-

ções no gerenciamento de atualizações. A abordagem comum para lidar com atu-
alizações tem sido usar transações para garantir consistência ao atualizar vários
recursos. Esta abordagem é frequentemente usada em monólitos;
Obs.: Esse seria o lado negativo de utilizar o microsserviço.

15m
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
• A utilização de transações ajuda na consistência, mas impõe um acoplamento

temporal significativo, que é problemático em vários serviços. As transações
distribuídas são notoriamente difíceis de implementar e, como consequência, as
arquiteturas de microsserviço enfatizam a coordenação sem transação entre os
serviços, com reconhecimento explícito de que a consistência pode ser apenas
a consistência eventual e os problemas são resolvidos pelas operações de
compensação;
Obs.: Ou seja, está acoplando de forma atemporal.
Existe a possibilidade de ter transações distribuídas, mas elas são bastante complicadas
de implementar. Geralmente, no microsserviço, não se trabalha tanto com Begin Transaction
como no modelo monolítico, trabalha-se com operações de compensação, ou seja, faz uma
operação e se ela der errado, o sistema de forma programada chama outra operação para
fazer a compensação disso. É um sistema menos seguro com relação a esse lado de con-
sistência dos dados, porque a transação garante a consistência. No entanto, a transação é
custosa, porque trava o banco de dados enquanto está ocorrendo.
• Optar por gerenciar as inconsistências dessa maneira é um novo desafio para

muitas equipes de desenvolvimento;
• Muitas vezes, as empresas lidam com um grau de inconsistência para responder
rapidamente à demanda, enquanto têm algum tipo de processo de reversão para
lidar com os erros;
• O trade-off vale a pena, desde que o custo de corrigir os erros seja menor do que
o custo de perda de negócios sob maior consistência.
Eventualmente, é possível que o sistema tenha uma inconsistência, por exemplo, uma
venda que foi feita e não tem mais produto no estoque é uma situação inconsistente, já foi
gravada na tabela de vendas, quando temos o sistema de transaction, conseguimos reverter
de uma forma mais fácil, quando estamos no sistema de banco de dados descentralizados
é um pouco mais difícil de contornar. Esse é o lado que dificulta o microsserviço, o fato de
geralmente não trabalhar com transações, e sim operações de compensação e é uma con-
sistência eventual do sistema.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
Automação de Infraestrutura
Obs.: É uma outra preocupação com o microsserviço.
• As técnicas de automação de infraestrutura evoluíram muito nos últimos anos – a

evolução da nuvem e da AWS, em particular, reduziu a complexidade operacional
de construir, implantar e operar microsserviços;
• Muitos dos produtos ou sistemas que estão sendo construídos com microsser-
viços estão sendo construídos por equipes com ampla experiência em Entrega
Contínua e seu precursor, a Integração Contínua. Equipes que constroem software
dessa maneira fazem uso extensivo de técnicas de automação de infraestrutura.
Lembrando que a integração contínua significa que cada vez que se faz uma entrega
no repositório de código fonte, ele vai fazer o teste, e, muitas vezes, vai fazer a entrega da
implantação desse pacote nesse ambiente de desenvolvimento.
A entrega contínua vai além, pode entregar em outros ambientes até chegar à produção
de uma forma contínua, mas desde que passe todos os testes.
20m
As equipes que constroem o software desta maneira fazem uso extensivo de técnicas de
automação de infraestrutura.
Essa automação de infraestrutura tem o que é chamado de pipeline, uma sequência

de passos.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
Ou seja, o microsserviço vai passar por todas essas fases, em geral, de uma forma auto-
matizada. Cada vez que se conclui uma fase, passa para a próxima, em que são executados
novos scripts e novas rotinas, até chegar ao momento em que é implantado em produção.
Isso é chamado de pipeline de desenvolvimento de implantação.
• Uma aplicação monolítica será construída, testada e transmitida por meio desses
ambientes de forma bastante feliz;
• Acontece que, depois de investir na automação do caminho para a produção de um
monolito, a implantação de mais aplicativos não parece mais tão complexa.
Se a empresa já teve um nível de dedicação para tornar mesmo seu monólito com uma
entrega contínua, uma implantação contínua será muito mais fácil se adequar ao microsser-
viço, porque vai aumentar a quantidade ativos que vão seguir o fluxo. No entanto, a automa-
ção já está pavimentada.
Design para Falha

• Uma consequência do uso de serviços como componentes é que os aplicativos
precisam ser projetados para tolerar a falha dos serviços;
• Qualquer chamada de serviço pode falhar devido à indisponibilidade do fornece-
dor, o cliente tem que responder a isso da maneira mais simples possível;
• Essa é uma desvantagem em comparação com um design monolítico. A consequ-
ência é que as equipes de microsserviço refletem constantemente sobre como as
falhas de serviço afetam a experiência do usuário.
Se aumentou a quantidade de microsserviço, aumenta a superfície de falha. 150 micros-

serviços distintos é bem mais possível que algum microsserviço falhe, ou tenha falha de con-
figuração, falha de máquina ou outra possibilidade. Então, o design de software tem que estar
sempre preparado para uma ocorrência de falha e superar essa falha da melhor maneira pos-
sível. Se possível, sem atingir o cliente.
• Como os serviços podem falhar a qualquer momento, é importante poder detectar

as falhas rapidamente e, se possível, restaurar automaticamente o serviço;
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
• Os aplicativos de microsserviços dão muita ênfase ao monitoramento em tempo

real do aplicativo, verificando os dois elementos de arquitetura (quantas solicita-
ções por segundo o banco de dados está obtendo) e métricas relevantes de negócios
(como quantas ordens por minuto são recebidas). O monitoramento semântico pode
fornecer um sistema de alerta antecipado de algo errado que aciona as equipes de
desenvolvimento para acompanhar e investigar.
25m
As duas principais monitorações são: 1) a de elementos de arquitetura, ou seja, hardware

para ver o funcionamento e 2) questão de negócio.
Muitos microsserviços devem ter um design orientado que espere que as coisas
deem errado.
Se o sistema de capitalização deu errado, não quer dizer que todo o sistema do banco vai
falhar imediatamente. É preciso estar preparado, pois algum componente do software pode
falhar. Uma das principais ou relevantes formas de fazer isso é ter uma monitoração eficiente.
Mas monitoração tanto no nível de software e hardware, isto é, tanto de mais baixo nível de
banco de dados quanto das métricas de negócios.
• Os monólitos podem ser construídos para serem tão transparentes quanto um

microsserviço – na verdade, deveriam ser;
• A diferença é que é necessário saber quando os serviços executados em diferen-
tes processos estão desconectados;
• Com bibliotecas dentro do mesmo processo, esse tipo de transparência é menos
provável de ser útil.
Design Evolutivo
• Os profissionais de microsserviço, em geral, vêm de um histórico de design evolu-
cionário e veem a decomposição de serviços como uma ferramenta adicional
para permitir que os desenvolvedores de aplicativos controlem as alterações em
seus aplicativos sem reduzir a velocidade das alterações. O controle de mudança
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
não significa necessariamente redução de mudança – com as atitudes e ferra-

mentas certas, é possível fazer alterações frequentes, rápidas e bem controladas
no software;
O microsserviço tenta trazer isso, um design em que possam ser feitas mais alterações
no software, que seja mais adequado ao mercado e às necessidades do cliente e mais rápida
que o monólito.
• Sempre que se tenta dividir um sistema de software em componentes, nos depara-

mos com a decisão de dividir as partes – quais são os princípios sobre os quais
decidimos dividir uma aplicação?
• A principal propriedade de um componente é a noção de substituição e capacidade
de atualização independentes – o que implica que procuramos pontos nos quais
possamos imaginar reescrever um componente sem afetar seus colaboradores.
Atualizar o software de maneira independente sem afetar os colaboradores.
• Esta ênfase na capacidade de substituição é um caso especial de um princípio

mais geral do design modular, que é conduzir a modularidade através do padrão
de mudança. O objetivo é manter as coisas que mudam ao mesmo tempo no mesmo
módulo. Partes de um sistema que mudam raramente devem estar em serviços dife-
rentes daqueles que estão atualmente passando por muita rotatividade. Caso dois
serviços sejam repetidamente alterados em conjunto, isso é um sinal de que
devem ser mesclados.
Exemplo: O processo de revisão cadastral e abertura de conta estão juntos, pois a aber-
tura de conta depende da revisão cadastral, neste caso, eles podem estar, então, no mesmo
microsserviço. Agora, se tiver capitalização e abertura de conta, são assuntos muito distintos,
então é provável que esteja em microsserviço distintos.
30m
• Com um monolito, qualquer alteração requer uma compilação e implementação

completas de todo o aplicativo. Com microsserviços, no entanto, só é necessá-
rio reimplantar os serviços modificados. Isso pode simplificar e acelerar o pro-
cesso de liberação. A desvantagem é que passa a ser necessário nos preocupar
com mudanças em um serviço que esteja quebrando seus consumidores;
DESENVOLVIMENTO WEB
Microsserviços III
• A abordagem de integração tradicional é tentar lidar com esse problema usando

o controle de versão, mas a preferência no mundo de microsserviço é usar somente
o controle de versão como último recurso. Podemos evitar muitos versionamentos,
projetando serviços para ser o mais tolerante possível às mudanças em seus
fornecedores.
É possível trabalhar com gerenciamento de mudança de versão, podendo versionar o

microsserviço, mas o ideal é que ele seja mais resiliente e suporte melhor as mudanças.
Por exemplo, um microsserviço que traz os dados do cliente como nome, telefone e
endereço, essa é uma versão do microsserviço. Agora uma outra versão vai trazer nome,
telefone, endereço, nome do pai e da mãe. O ideal é que nesse caso nem precise versionar,
simplesmente estamos aumentando a quantidade de respostas, então para os serviços ante-
riores, que não esperavam essa resposta, o ideal é que não quebrem e simplesmente igno-
rem essa informação adicional. Com isso, conseguimos ser mais resilientes às mudanças no
microsserviço.
DIRETO DO CONCURSO
1. (CESPE/TRT- 8ª Região (PA e AP)/TÉCNICO JUDICIÁRIO-TECNOLOGIA DA INFOR-
MAÇÃO/2016) Acerca da arquitetura de microsserviços, assinale a opção correta.
a. A arquitetura de microsserviços é um padrão para a criação de aplicações distribuí-
das, porém não possui alta escalabilidade.
b. A comunicação entre os microsserviços é feita por meio de mecanismos padrões de
tecnologia, como, por exemplo, o REST (representational state transfer).
c. Microsserviços utilizam uma única base de dados lógica para a persistência de dados.
d. Um requisito fundamental da arquitetura de microsserviços é o uso de versionamento
de mudanças.
e. Os microsserviços são componentes autônomos e de alto acoplamento, de modo que
há a necessidade de se utilizar uma mesma linguagem na sua construção.
ANOTAÇÕES
DESENVOLVIMENTO WEB
Microsserviços III
COMENTÁRIO
a. Possui alta escalabilidade. Conseguimos escalar melhor os microsserviços, que é um
dos objetivos dele.
c. Descentralizam a governança da base de dados.
d. Pode ser, mas não é fundamental. É uma possibilidade usar o versionamento de mudanças.
e. É baixo acoplamento e alta coesão e não precisam ser na mesma linguagem.
Obs.: Essa questão é importante para entender os conceitos de microsserviço.
2. (CESPE/EMAP/ANALISTA PORTUÁRIO-TECNOLOGIA DA INFORMAÇÃO/2018)

Com relação a redes e serviços, julgue o item subsequente.
Os microsserviços são serviços autônomos, independentes e implantáveis indepen-
dentemente.
COMENTÁRIO
Os microsserviços são autônomos e por essa característica são independentes e implan-
táveis de forma independente.
GABARITO
1. b
2. C
ANOTAÇÕES

ARQUITETURA

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ARQUITETURA

Enviado por

Direitos autorais:

Formatos disponíveis

DESENVOLVIMENTO WEB

O livro à esquerda é clássico da matéria. É calcado em C++. O da direita é baseado em

Os design patterns (padrões de projeto) representam as melhores práticas usadas por

Gang of Four (GoF)

Benefícios e Problemas da Herança

Entre os problemas da herança está o fraco encapsulamento entre classes e subclasses

A seta fechada significa que o carro possui um motor.

Benefícios e Problemas da Composição

Quando Usar Composição ou Herança

PLATAFORMA COMUM PARA DESENVOLVEDORES

Os padrões de projeto fornecem uma terminologia padrão e são específicos para um

Os padrões de projeto foram desenvolvidos durante um longo período de tempo e forne-

TIPOS DE PADRÕES DE PROJETO

De acordo com o livro Design Patterns – Elementos de Software Orientado a Objetos

b. Padrões de análise, padrões estruturais e padrões comportamentais.

Na sequência, está a parte direita do esquema.

O código abaixo mostra o que está consumindo a factory:

ABSTRACT FACTORY / FÁBRICA ABSTRATA

É pouco usada na prática da programação. É mais elaborada do que a fábrica simples,

Exemplo: quando queremos compartilhar informações num mesmo sistema.

O padrão de protótipo refere-se à criação de objetos duplicados, mantendo o desempe-

I – Padrões de projeto de criação são aqueles que abstraem o processo de instanciação

2. (INAZ DO PARÁ/CORE-SP/ANALISTA DE T.I/2019) “Em 1995 Erich Gama, Richard

Qual padrão de projeto tem o propósito de assegurar o controle da quantidade de ins-

DESIGN PATTERNS III

É uma construção rebuscada, dando suporte ao mp3, ao mp4 e ao vlc.

Independente da complexidade, na hora da utilização será simples, sem a preocupação

O padrão de filtro ou Criteria é um padrão de design que permite aos desenvolvedores

O padrão de composição é usado onde precisamos tratar um grupo de objetos de maneira

a. o Adapter permite que classes com interfaces incompatíveis trabalhem em conjunto.

em termos de uma estrutura em árvore para representar parte e toda a hierarquia.

DESIGN PATTERNS – PADRÕES DE PROJETO

Diagrama – Programa DecoratorPatternDemo

Obs.: ShapeDecorator é uma interface implementada pela RedShapeDecorator, a

Em termos de códigos: há uma interface Shape, um retângulo, um círculo e o Decorator.

O ShapeDecorator receberá uma forma decorada e no seu construtor ganhará o formato

Tem-se aqui o RedShapeDecorator que estende o ShapeDecorator, recebendo uma

Na implementação, como um todo do programa DecoratorPatterDemo, há um círculo e

Diagrama – Programa FacadePatternDemo

Novamente, tem-se o Shape, o Circle, o Rectangle e também o Square. Do outro lado,

Há, nessa parte, a execução do sistema FacadePatternDemo. Nela, seriam necessários

O padrão Flyweight tenta reutilizar objetos do tipo semelhantes já existentes, armaze-

Diagrama – Programa FryWeightPatternDemo

Há aqui a interface do Shape e o Circle. Do outro lado, o FlyWeightPattern, que é o pro-

O programa FlyweightPatternDemo, de maneira geral, coloca uma lista de cores (Red,

A execução desse programa Java cria objetos, conforme a necessidade. Populando o

Diagrama – Programa ProxyPatterDemo

Observa-se aqui a Image (Inteface) e a RealImage que a implementa. No momento da

O programa em execução public class ProxyPatternDemo tem um main, ou seja, um

Chain of Responsibility / Cadeia de Responsabilidade

Diagrama – Programa ChainPatternDemo

No AbstractLogger, tem-se algumas constantes. Na parte inferior do diagrama, há vários

Obs.: O nextLogger indica a existência de uma cadeia.

Na AbstractLogger, há o INFO, DEBUG e ERROR e a indicação do nível que ela está

Obs.: Em cada uma dessas implementações, existirão diferenças.

Execução do programa: AbstratactLogger getChainofLoggers, uma cadeia de Loggers.

1. (CESPE/2018/CGM DE JOÃO PESSOA/PB/AUDITOR MUNICIPAL DE CONTROLE

O Adapter não se relaciona com a questão da quantidade de múltiplos objetos, mas o

O padrão de comando é um padrão de design controlado por dados e se enquadra na

Diagrama – Programa CommandPatternDemo

À esquerda do CommandPatternDemo, há o sistema de ações. Esse sistema liga-se ao

O CommandPatternDemo possui um programa principal para criar o new Stock, uma

O padrão do intérprete fornece uma maneira de avaliar a gramática ou expressão da lin-