Aula 02 - Padrões de Projeto GOF, Java EE e GRASP

Curso de Desenvolvimento de Software para Concursos
Profs. Diego Carvalho e Leon Sólon – Aula 02
Suponham que haja uma fábrica de software que desenvolve diversos sistemas
para as mais variadas áreas de negócio. Sabe-se que, mesmo em áreas
aparentemente distintas ou contrastantes, grande parte os problemas já possuem
uma lução conhecida, formalmente ocumentada xaustivamente t stada,
uma z que am de roblemas recorrentes.
Portanto, não há necessidade de se resolver o problema

do início se já existe uma solução adequada. Assim sendo,
os padrões de rojeto s o modelos ara solucionar
problemas gerais de projeto m um ntexto particular.
Poxa, professor... o engenheiro de software que inventou
isso era genial, né?! Qual é, pessoal! Mais uma vez, nós
“roubamos” isso de outras engenharias. Em meados de
1977, um sujeito chamado Christopher Alexander
(arquiteto, matemático e urbanista austríaco) estudava
como melhorar o projeto de edifícios. Ao se cansar de
observar repetidos problemas, ele lançou um anifesto
com o egistro e diversos padrões de rojeto ecorrentes
na engenharia il.
Esse manifesto continha algumas regras e figuras que descreviam métodos para a
construção de projetos práticos, seguros e atrativos em quaisquer escalas, desde
regiões inteiras a cidades, vizinhanças, jardins, edifícios, salas, entre outros. Cada
padrão i testado ndo eal, sendo revisado por diversos arquitetos e
engenheiros.
Alexander ez uma mportante eclaração a espeito de adrões de rojeto e
arquitetura: “Cada padrão descreve um problema que ocorre repetidas vezes em
nosso ambiente e, então, descreve o núcleo da solução para aquele problema, de
tal maneira que pode-se usar essa solução milhões de vezes sem nunca fazê-la da
mesma forma duas vezes”.
Bem, isso chamou a atenção de programadores que estavam de saco cheio de ter
que refazer várias partes do código para cada projeto. Foi então que, em 1994
quatro ngenheiros de ftware, conhecidos como The ng of Four (GoF),
resolveram compilar ibliotecas de luções para roblemas comuns de
codificação e lançaram um livro com 23 Padrões de Projeto de Software.
Esse livro se tornou um clássico best-seller da literatura orientada a objetos e é

recomendado na nossa bibliografia, não obstante ser de leitura extremamente
técnica. Concernente aos padrões de rojeto, os autores desse o izem: “São
Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 3 de 115

descreve como resolvê-lo; e Consequência descreve os impactos.
Por algumas observações importantes! Esses 23 Design Patterns somente

podem ser utilizados em projetos de tecnologia da informação? Claro, eles são
padrões de projeto de software. Esses 23 Design Patterns somente podem ser
utilizados em projetos orientados a objetos? Sim, também. Pessoal, Padrões GOF
somente com OO! Padrões de Projeto, em geral, podem usar qualquer paradigma
ou linguagem!
Os 23 Padrões de Projeto podem ser classificados quanto aos seus propósitos em

três tipos: Padrões Criacionais, Padrões Estruturais e Padrões Comportamentais.
Infelizmente, vocês têm que ecorar omo ssificam todos os padrões de
projeto. A tabela acima apresenta todos os padrões de acordo com seus
respectivos propósitos.
Os Padrões Criacionais abstraem o processo de criação de objetos a partir da

instanciação de classes. Já os Padrões Estruturais tratam da forma como classes e
objetos estão organizados para formar estruturas maiores. Por fim, Padrões
Comportamentais se preocupam com os algoritmos e responsabilidades dos
objetos, que ocorrem em tempo de execução.
Pessoal... quando eu estudei esse assunto na minha vida de concurseiro, eu tive

uma ajuda sensacional para decorar essa classificação! Eu me utilizei de um
mnemônico enialmente iado por rofessor c ado gério Araújo para -
a partir de duas frases bastantes simples - decorar os padrões criacionais e
estruturais, como mostra imagem abaixo.

Explicação: A fábrica (Factory Method) abstrata (Abstract Factory) constrói (Builder)

um protótipo (Prototype) único (Singleton). A ponte (Bridge) adaptada (Adapter) é
composta (Composite) de decorações (Decorator) na fachada (Façade) para o
peso-mosca (Flyweight) se aproximar (Proxy). E não tem frase para o último? Não,
se o é iacional ou estrutural, é mportamental.

ícones, etc), que compunham a interface de um website em um smartphone ou

desktop.
Ao se descobrir de que dispositivo se tratava, instanciava-se a interface completa

do smartphone ou desktop. Agora ponham que blete ja apaz de eunir
simultaneamente elementos de mbas as interfaces gráficas. O Builder é capaz de
coordenar a construção da interface gráfica do tablete ao instanciar partes dessas
duas interfaces.
Portanto, ele pode criar diferentes representações de suas interfaces gráficas ao

instanciar, por exemplo, um botão da interface do smartphone, a barra de
rolagem da interface do desktop, caixas de seleção da interface do smartphone e
ícones da interface do desktop. O Builder ossui uma c asse que oordena a
construção esses objetos até a iação da epresentação final.
 Factory Method: define uma interface para criar um objeto, mas deixa s
subclasses decidirem qual classe instanciar.
Pessoal, esse adrão de rojeto eve r tilizado uando a asse puder

antecipar ual objeto ela deve iar. Deve ser usado, também, quando uma classe
quer que suas subclasses especifiquem os objetos que ela criar. Por fim, deve ser
usado para delegar responsabilidades a diversas outras subclasses. Considerem a
hipótese de se visualizar as características de um carro de uma concessionária.
No entanto, sabe-se que em uma concessionária há diversos modelos de carro.

Então, pode-se criar uma classe abstrata base para representar todos os carros e
especializá-la em subclasses que representem cada tipo de carro (Corsa, Celta,
Cruze, Camaro, etc). No ntanto, o problema urge quando quer iar
objeto, uma z que e lguma rma recisa-se dentificar qual objeto
deseja iar.
O Factory Method ia bjetos concretos que plementam a asse ase

especializam cada bjeto, sendo definidos, pelo usuário, em tempo e xecução,
qual carro deverá ser nstanciado. É bom destacar que ele – conforme especificado
– contém diversos elementos, tais como: Creator, ConcreteCreator, Product e
ConcreteProduct.

 Prototype: especifica os tipos de objetos para criar usando uma instância mo

protótipo e cria novos objetos copiando este protótipo.
Pessoal, esse padrão e projeto eve r ut lizado quando um tema possuir

componentes cujo stado ial tenha oucas variações. É oportuno disponibilizar
um conjunto pré-estabelecido de protótipos que dão origem aos objetos que
compõem o sistema. Dessa forma, basta modificar os atributos que forem
diferentes e adaptar o objeto para o uso pretendido.
Considerem a hipótese de se preencher os dados de todas as pessoas de uma

família e que cada objeto Pessoa contenha centenas de atributos, tais como:
Nome, Idade, Endereço, Telefone Residencial, Nacionalidade, Classe Social, etc.
Vamos supor que sejam preenchidos todos os atributos do objeto Pessoa
referente o pai, mas ainda lta preencher s dados da s.
Portanto, sabe-se que tributos como dereço, Telefone esidencial,

Nacionalidade, etc provavelmente s rão dênticos para t dos os membros da
família. Logo, ao invés de se criar um novo objeto para cada membro e preenchê-
los um a um integralmente, pode-se clonar o objeto pai já preenchido e modificar
apenas os atributos diferentes, como Nome, Idade, entre outros.
Entre os benefícios adicionais decorrentes da lização desse adrão, inserem-se:

acrescenta e remove produtos em tempo de execução; reduz o número de
subclasses; configura dinamicamente uma aplicação com classes; especifica novos
objetos pela variação de valores; e especifica novos objetos pela variação da
estrutura. Bacana?
 Singleton: garante que uma classe tenha apenas uma stância e provê um
ponto de cesso global a ela.
Pessoal, esse padrão de projeto deve ser utilizado quando houver a necessidade
de existir exatamente uma instância de uma classe e ela deverá ser acessível aos
clientes a partir de um ponto de acesso conhecido. Vamos considerar pótese
de um sistema que r balhe com diversas conexões com o banco e ados em
uma sma execução.
Imaginem a erda e desempenho o e anciar lasse de nexão om o

banco e ados várias vezes. O Padrão Singleton resolve esse problema ao
garantir que só haverá uma instância de conexão com o banco de dados e, assim,

hierarquias de classes relacionadas. Esse adrão e rojeto pouco

complicado de e entender, portanto prestem atenção!
Considerem a hipótese de um conjunto de janelas gráficas que funcionem em

diversas plataformas (Windows, Linux, Mac, etc). Professor, por que não usar o
Adapter? De a o ele oderia adaptar erfaces para ada a das plataformas.
No entanto, há dezenas de tipos de janelas gráficas (Diálogo, Aviso, Erro, etc),
tornando a utilização inviável para grandes quantidades.
Uma deia lhor ria iar a t rface para s plataformas utra para s
janelas. A primeira conteria os elementos comuns das plataformas e teria classes
concretas específicas para implementar janelas em Linux, Mac, etc. A segunda
conteria os elementos comuns das janelas e teria classes concretas específicas para
implementar Janelas de Diálogo, Aviso, Erro, etc.
Portanto, ao ar todo da lasse oncreta a terface e anelas, ela

realizará amadas aos métodos concretos da nterface de plataformas. Assim,
caso se queira adicionar mais tipos de janelas ou mais plataformas, não haverá
impacto no cliente, não haverá recompilação de código e não haverá vínculo entre
as interfaces de um e implementações de outros.
O desacoplamento permite que se modifique o código da interface de

plataformas sem alterar a implementação das janelas e vice-versa. Vocês
percebem que, assim, pode-se combinar as interfaces e implementações de
quaisquer maneiras possíveis? Pois é, esse grande enefício do adrão B idge.
Como nós vimos anteriormente, basta lembrar de uma ponte.
 Composite: compõe objetos em estruturas de rvore para representar

hierarquias parte-todo, permitindo aos clientes tratarem objetos individuais e
composições de objetos uniformemente.
Pessoal, esse padrão de projeto deve ser utilizado quando se deseja representar
hierarquias parte-todo de objetos e quando se deseja que os clientes ignorem a
diferença entre composições de objetos e objetos individuais. Assim, eles ra arão
todos os objetos em uma strutura mposta iformemente. Considerem a
hipótese de uma interface gráfica composta de vários objetos.
Em muitos casos, esses objetos são mpostos de utros objetos. Uma excelente
implementação dessa interface seria, por exemplo, por meio de uma árvore,

porém tudo deve ser transparente para o cliente – ele precisa saber de nada disso.
Dessa forma, ele não deve diferenciar objetos individuais (Folhas) de outros
objetos compostos (Nós).
 Decorator: anexa esponsabilidades adicionais a um objeto dinamicamente.

Fornece uma alternativa flexível em relação à herança para estender
funcionalidades.
Pessoal, esse padrão de projeto deve ser utilizado quando se quer adicionar
responsabilidades a objetos individuais dinâmica e transparentemente, i.e., sem
afetar utros objetos. Também é utilizado quando extensões por subclasses forem
impraticáveis, tendo em vista o possível número de extensões independentes.
Considerem a hipótese de um Subway!
Usando-se rança, cria-se a asse bstrata duíche á as classes

concretas para plementá-la. No entanto, há sanduíches com almôndega, sem
queijo, com tomate, sem cebola, etc. É customizável, portanto é completamente
inviável construir classes concretas para cada tipo de sanduíche, devido a
gigantesca quantidade de combinações.
O Padrão Decorator sugere que o objeto sanduíche anexe diversas

responsabilidades dinamicamente. Dessa forma, em tempo de xecução, à dida
que se dicione u vo grediente, cria-se ais uma esponsabilidade. Ao
contrário da herança, que aplica funcionalidades a todos os seus objetos, o
Decorator aplica apenas a um objeto específico.
 Façade: oferece uma interface u ificada para um conjunto de interfaces em um

subsistema, definindo uma interface de alto nível que facilita a utilização do
subsistema.
Pessoal, o Padrão de Projeto Façade (também é um dos mais importantes) deve

ser utilizado quando se desejar fornecer uma interface simples para um subsistema
complexo ou também quando se deseja dividir em camadas os subsistemas. É
também utilizando uando existem diversas dependências entre e tes e s
classes de plementação de u a bstração.
Considerem a hipótese de um banco com um sistema legado de informações de

crédito muito complexo, que deve interagir com um sistema de banco de dados

recém implementado. Para que ele acesse o sistema legado, pode-se utilizar o
padrão Façade para acilitar lização por io de a erface e lto nível e,
assim, não d se t ragir diretamente m o t ma mplexo.
 Flyweight: usa compartilhamento para suportar eficientemente grandes

quantidades de bjetos de baixa granularidade.
Pessoal, esse padrão e projeto eve s r t zado quando uma plicação usa
grande mero e bjetos e s tos de rmazenamento rem altos. Deve ser
utilizado, também, quando muitos grupos de objetos puderem ser substituídos
por relativamente poucos objetos compartilhados, uma vez que os estados
extrínsicos forem removidos.
Considerem a pótese e t xto scrito soft Word, em que

caractere ja m objeto ue ntenha osição, formato e tamanho – isso poderia
ocupar toda memória disponível no sistema, mas percebam que vários caracteres
se repetem diversas vezes (ex: letra A) e eles são exatamente iguais, muda-se
somente a posição (ex: 200 ocorrências da letra A em várias posições).
Portanto, cada caractere deve possuir uma referência para um objeto Flyweight,
que deverá ser compartilhado por todas as instâncias do mesmo caractere do
documento, exceto a posição que será variável. Portanto, em vez de armazenarem
800 bjetos com três atributos, armazenam-se 00 objetos com um tributo e
ponteiro para bjeto yweight.
 Proxy: provê um substituto ou ponto através do qual um objeto pode controlar

o acesso a outro objeto.
Pessoal, esse padrão de projeto deve ser utilizado quando houver uma
necessidade de uma referência mais versátil ou sofisticada para um objeto do que
um simples ponteiro. Por exemplo, proxies ais criam objetos caros por
demanda proxies e proteção controlam o cesso o bjeto riginal.
Considerem a hipótese de um sistema que acesse um banco de dados por meio
de uma classe de conexão.
No ntanto, por edidas de gurança, vamos supor que e eseja que sse
sistema não tenha cesso direto o anco e dados referido. Dessa forma, o
usuário se conectará ao Proxy (i.e., a classe substituta ou suplente) e o Proxy que

coleções. O Iterator permite que se percorra todas essas coleções sem precisar
saber detalhes de seu funcionamento.
 Mediator: define um objeto que encapsula rma como m conjunto de

objetos interagem, promovendo um fraco acoplamento ao evitar que objetos se
refiram aos outros explicitamente.
Pessoal, esse padrão de projeto deve ser utilizado quando um conjunto de objetos
se comunicar de maneira bem definida, porém complexa e quando o reúso de um
objeto for difícil por referenciar e se comunicar com muitos outros objetos.
Ademais, ele é t izado quando mportamento distribuído ntre diversas
classes puder r tomizado s m a iação de itas subclasses.
Considerem a pótese de ftware mplexo com grandes quantidades de

classes, de t l modo que ó ica de rocessamento stá istribuída ntre las.
Todo mundo sabe que, há cada manutenção ou refatoração, o desenho do
software pode se tornar mais complexo e a comunicação entre as classes pode ser
mais difícil de ler entender.
Portanto, o drão ediator ermite ue municação entre objetos seja

encapsulada m um utro objeto diador. Assim, não haverá mais uma
comunicação direta entre as classes, reduzindo o acoplamento, garantindo que
todos fiquem mais livres para serem modificados e diminuindo a complexidade de
comunicação entre objetos.
 Memento: captura xternaliza stado t rno e u bjeto, sem violar seu

encapsulamento, de maneira que o objeto possa ser restaurado posteriormente.
Pessoal, esse padrão e projeto eve r t lizado quando a parte o stado

de bjeto recisar r rmazenada, de rma que possa r ecuperada
posteriormente. Ele é utilizado, também, para evitar que uma interface direta para
obter um estado exponha detalhes de implementação e quebrem o
encapsulamento do objeto.
Considerem a hipótese de um editor de texto que guarde o estado interno do

objeto, i.e., o que o usuário está digitando, aí ele deleta uma palavra, mas se
arrepende e deseja voltar ao estado anterior. Bem, o mento oferece a

maneira de esfazer ções sem ter cesso o ue stava ndo escrito, ele apenas
retorna o estado nterior, mas sem olhar o que estava escrito.
Portanto, o Padrão Memento permite a captura e externalização do estado interno

de um objeto, sem violar seu encapsulamento, i.e., ele captura o que estava escrito
e mostra ao usuário, porém sem ter acesso direto ao que estava escrito. Dessa
forma, pode-se celar perações e esfazer lterações para etornar ao stado
anterior.
 Observer: define uma dependência um-para-muitos entre objetos para que,

quando bjeto udar de stado, os seus dependentes sejam notificados e
atualizados automaticamente.
Pessoal, esse padrão de projeto deve ser utilizado quando uma mudança em um
objeto requisitar mudanças em outros e não se souber quantos objetos
necessitam ser modificados. Ele também é zado quando a bstração
possuir dois aspectos, um dependente o utro. Ademais, é recomendado
quando um objeto for capaz de notificar outros sem assumir quem são.
Considerem a hipótese de uma tabela de classificação do campeonato brasileiro

com um gráfico de pizza informando vitórias, empates e derrotas de um
determinado time, assim como um gráfico com a variação de posição do time do
campeonato. Aí chega o domingão, ocorrem 10 o os e o estagiário altera a
tabela om os novos dados.
E agora? Como ficam os gráficos? Tem que atualizar cada um na mão? Enquanto
ele não atualiza, os gráficos ficarão desatualizados? Não haverá nem uma
notificação de que há novos dados? Bem, o padrão Observer serve para isso! Ele
cria a dependência dos gráficos em relação à tabela de do ue, quando a
tabela da e estado, os gráficos são atualizados automaticamente.
 State: permite a um objeto alterar o seu comportamento quando o seu estado

interno or dificado.
Pessoal, esse padrão de projeto deve ser utilizado quando o comportamento de

um objeto depender de seu estado e ele deve mudar este comportamento em
tempo de execução de acordo com este estado. Ademais, é ecomendado

quando perações tiverem declarações condicionais grandes que ependam do

estado o bjeto.
Considerem a hipótese do jogo Super Mario Bros! Lembram-se de quando ele

conseguia uma flor de fogo? Se le stivesse pequeno, ele icava rande
pegando ogo! e ele estivesse grande, ele ficava egando fogo! Se ele já
estivesse pegando fogo, ele ganhava 1000 pontos! Se ele tivesse com uma capa
de voo, ele perdia a capa e ficava pegando fogo!
Portanto, notem que o stado turo epende e u stado tual e stado

futuro ecidido m tempo de xecução, i.e., durante go. O Padrão State
elimina a necessidade de condicionais complexos, tendo em vista que podem
haver dezenas ou centenas de estados possíveis. A grande vantagem é que esta
solução torna mais simples adicionar estados e suas transições.
 Strategy: define uma família de lgoritmos, encapsula cada um e faz deles

intercambiáveis.
Pessoal, esse padrão de projeto deve ser utilizado quando várias classes
relacionadas diferirem apenas em seus comportamentos e que houver
necessidade de diferentes variantes de um algoritmo. Ele também é ut zado
quando u a asse definir muitos comportamentos e les parecerem como
declarações condicionais em suas operações.
Considerem a hipótese de uma escola querer organizar os meninos e as meninas

por ordem de idade. Há a ília e lgoritmos paz de ealizar ssa
operação (BubbleSort, QuickSort, Heapsort, ergeSort, etc). Uma maneira de
realizar essa operação é por meio de operadores condicionais (if-else), porém isso
pode ser muito trabalhoso em grandes quantidades.
Uma oa estratégia seria encapsular os algoritmos de ordenação, de modo que se

possa trocar de lgoritmo mpre que quiser. Assim, basta chamar o método
OrdenaAluno com os parâmetros sexoAluno e algoritmoOrdenacao. Dessa forma,
é possível chamar o método ordenaAluno(menino, bubbleSort) ou
ordenaAluno(menina, mergeSort), etc, diminuindo o acoplamento.
 Template thod: define o esqueleto e u lgoritmo dentro de uma

operação, deixando alguns passos a serem preenchidos pelas subclasses.

Pessoal, se tiver com o tempo apertado, estudem apenas esses acima! Do esmo
modo, podemos afirmar que, dos 23 P drões de P ojeto, onze rrespondem à
15% as questões de prova: Decorator, Flyweight, Proxy, Chain of Responsability,
Interpreter, Mediator, Memento, State, Strategy e Template Method. Os seis
padrões restantes, estão no meio termo e correspondem a 30% das questões de
prova. Para concursos da Fundação Carlos Chagas, vale dar uma olhada no
Factory Method também, pois eles adoram cobrar.

P DRÕES DE PROJETO GRASP)
O GRASP, acrônimo de General Responsability Assignment Software Patterns (ou

Principles), consiste em um conjunto de ráticas que descrevem os princípios
fundamentais de tribuição e esponsabilidade a bjetos, expressas na forma de
padrões. Ele ajuda a compreender melhor a utilização da orientação a objetos em
projetos complexos.
A qualidade de um projeto orientado a objetos está fortemente relacionada à

distribuição de responsabilidades, que podem ser divididas em Responsabilidade
de Conhecimento (Knowing) e Responsabilidade de Realização (Doing). A primeira
refere-se istribuição das características do t ma entre s classes e gunda
à istribuição o mportamento o ma entre s classes.
As Responsabilidades do Tipo Realização são realizadas por um único método ou

uma coleção de métodos trabalhando em conjunto. Já as Responsabilidades do
Tipo Conhecimento são inferidas a partir do modelo conceitual, i.e., são atributos e
relacionamentos. Lembram-se da UML? Pois é, os Diagramas de nteração são
bastante t lizados para epresentar responsabilidades.
Galera, para ser em sincero m vocês, eu onsidero Pa rões GRASP mais como
uma o ofia de projeto o que mo m conjunto de padrão e projeto. Eles
descrevem princípios fundamentais de desenho orientado a objetos e definição de
responsabilidades, expressos em padrões. Vocês sabem o que significa o verbo To
Grasp? Significa tomar, agarrar, apreender, captar, aferrar, pegar de súbito.
Esse nome foi escolhido com o intuito de sugerir a importância de agarrar ou

captar esses princípios para desenhar projetos de software orientados a objetos da
melhor forma possível. Os Padrões de P ojeto GOF xploram soluções de projeto
mais específicas, já os Padrões de Projeto GRASP refletem ráticas mais pontuais
da plicação de écnicas orientadas a objetos.
O Padrão G A P mposto e P drões B s quatro P drões

Avançados. Os Padrões Básicos são: Information Expert, Creator, High Cohesion,
Low Coupling e Controller. Já os Padrões Avançados são: Polymorphism, Pure
Fabrication, Indirection e Protected Variations. Assim como os Padrões de Projeto
(GOF), para resolver a grande maioria das questões, basta conhecer a descrição
básica.

 Expert:
Também conhecido como Information Expert, esse padrão é utilizado para

determinar para quem delegar as responsabilidades. Essas responsabilidades
incluem métodos, campos calculados, etc. Deve-se tribuir esponsabilidade o
especialista a ormação, isto é., a asse ue possui a ormação necessária
para isfazer essa responsabilidade.
 Creator:
A criação de objetos é u a das atividades mais comuns em sistemas orientados a

objetos. Esse padrão é responsável por criar objetos de classes, sendo uma
propriedade fundamental do relacionamento entre objetos em determinadas
classes, i.e., possui a responsabilidade unívoca pela criação de uma nova instância
de uma classe.
 High Cohesion:
Esse padrão usca anter bjetos propriadamente ocados, gerenciáveis e

compreensíveis. Geralmente é utilizado para suportar o baixo acoplamento,
enfatizando que as responsabilidades de um dado elemento são fortemente
relacionadas e altamente focadas. Eu sempre decorei assim: “Coesão é a divisão
de responsabilidades”.
 Low Coupling:

Esse padrão identifica pontos de variação ou instabilidades potenciais e atribui

responsabilidades para criar uma interface estável em volta desses pontos. Dessa
forma, ela protege elementos das variações de outros elementos (objetos,
sistemas, subsistemas) ao envolver co e abilidade m uma rface
usando o olimorfismo ara iar as implementações desta erface.

Essas soluções estão organizadas em três famílias conforme o propósito de

cada solução.
Os padrões de projetos denominados Interpreter, Prototype e Flyweight que

fazem parte desse catálogo, pertencem, respectivamente, às seguintes famílias:
a) padrão comportamental, padrão de criação e padrão estrutural.

b) padrão estrutural, padrão comportamental e padrão de criação.
c) padrão comportamental, padrão estrutural e padrão de criação.
d) padrão estrutural, padrão de criação e padrão comportamental.
e) padrão de criação, padrão comportamental e padrão estrutural.

Aula 02 - Padrões de Projeto GOF, Java EE e GRASP

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 02 - Padrões de Projeto GOF, Java EE e GRASP

Enviado por

Dados do documento

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

Aula 02 - Padrões de Projeto GOF, Java EE e GRASP

Enviado por

Direitos autorais:

Formatos disponíveis

Curso de Desenvolvimento de Software para Concursos

Profs. Diego Carvalho e Leon Sólon – Aula 02

Portanto, não há necessidade de se resolver o problema

Esse livro se tornou um clássico best-seller da literatura orientada a objetos e é

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 3 de 115

descreve como resolvê-lo; e Consequência descreve os impactos.

Por algumas observações importantes! Esses 23 Design Patterns somente

Os 23 Padrões de Projeto podem ser classificados quanto aos seus propósitos em

Os Padrões Criacionais abstraem o processo de criação de objetos a partir da

Pessoal... quando eu estudei esse assunto na minha vida de concurseiro, eu tive

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 5 de 115

Explicação: A fábrica (Factory Method) abstrata (Abstract Factory) constrói (Builder)

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 6 de 115

ícones, etc), que compunham a interface de um website em um smartphone ou

Ao se descobrir de que dispositivo se tratava, instanciava-se a interface completa

Portanto, ele pode criar diferentes representações de suas interfaces gráficas ao

Pessoal, esse adrão de rojeto eve r tilizado uando a asse puder

No entanto, sabe-se que em uma concessionária há diversos modelos de carro.

O Factory Method ia bjetos concretos que plementam a asse ase

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 8 de 115

 Prototype: especifica os tipos de objetos para criar usando uma instância mo

Pessoal, esse padrão e projeto eve r ut lizado quando um tema possuir

Considerem a hipótese de se preencher os dados de todas as pessoas de uma

Portanto, sabe-se que tributos como dereço, Telefone esidencial,

Entre os benefícios adicionais decorrentes da lização desse adrão, inserem-se:

Imaginem a erda e desempenho o e anciar lasse de nexão om o

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 9 de 115

hierarquias de classes relacionadas. Esse adrão e rojeto pouco

Considerem a hipótese de um conjunto de janelas gráficas que funcionem em

Portanto, ao ar todo da lasse oncreta a terface e anelas, ela

O desacoplamento permite que se modifique o código da interface de

 Composite: compõe objetos em estruturas de rvore para representar

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 11 de 115

 Decorator: anexa esponsabilidades adicionais a um objeto dinamicamente.

Usando-se rança, cria-se a asse bstrata duíche á as classes

O Padrão Decorator sugere que o objeto sanduíche anexe diversas

 Façade: oferece uma interface u ificada para um conjunto de interfaces em um

Pessoal, o Padrão de Projeto Façade (também é um dos mais importantes) deve

Considerem a hipótese de um banco com um sistema legado de informações de

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 12 de 115

 Flyweight: usa compartilhamento para suportar eficientemente grandes

Considerem a pótese e t xto scrito soft Word, em que

 Proxy: provê um substituto ou ponto através do qual um objeto pode controlar

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 13 de 115

 Mediator: define um objeto que encapsula rma como m conjunto de

Considerem a pótese de ftware mplexo com grandes quantidades de

Portanto, o drão ediator ermite ue municação entre objetos seja

 Memento: captura xternaliza stado t rno e u bjeto, sem violar seu

Pessoal, esse padrão e projeto eve r t lizado quando a parte o stado

Considerem a hipótese de um editor de texto que guarde o estado interno do

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 16 de 115

Portanto, o Padrão Memento permite a captura e externalização do estado interno

 Observer: define uma dependência um-para-muitos entre objetos para que,

Considerem a hipótese de uma tabela de classificação do campeonato brasileiro

 State: permite a um objeto alterar o seu comportamento quando o seu estado

Pessoal, esse padrão de projeto deve ser utilizado quando o comportamento de

Profs. Diego Carvalho e Leon Sólon www.estrategiaconcursos.com.br Pág. 17 de 115

quando perações tiverem declarações condicionais grandes que ependam do

Considerem a hipótese do jogo Super Mario Bros! Lembram-se de quando ele

Portanto, notem que o stado turo epende e u stado tual e stado