Escolar Documentos
Profissional Documentos
Cultura Documentos
14 de junho de 2015
As apostilas atualizadas esto disponveis em www.k19.com.br
Sumrio i
Sobre a K19 1
Seguro Treinamento 2
Termo de Uso 3
Cursos 4
1 Introduo 5
1.1 Sistemas Corporativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Orientao a Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Padres de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Padres de criao 7
2.1 Factory Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Abstract Factory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Abstract Factory + Factory Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.6 Exerccios Complementares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7 Builder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.8 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.9 Prototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.10 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.11 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.12 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.13 Multiton (no GoF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.14 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.15 Object Pool (no GoF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.16 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
www.facebook.com/k19treinamentos i
S UMRIO ii
3 Padres Estruturais 41
3.1 Adapter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3 Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5 Composite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7 Decorator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.8 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.9 Facade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.10 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.11 Front Controller (no GoF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.12 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.13 Flyweight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.14 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.15 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.16 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4 Padres Comportamentais 81
4.1 Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
4.2 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.3 Iterator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
4.4 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.5 Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.6 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.7 Observer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.8 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.9 State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.10 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.11 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.12 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.13 Template Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.14 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.15 Visitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.16 Exerccios de Fixao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
ii www.k19.com.br
1 S UMRIO
Sobre a K19
A K19 uma empresa especializada na capacitao de desenvolvedores de software. Sua equipe
composta por profissionais formados em Cincia da Computao pela Universidade de So Paulo
(USP) e que possuem vasta experincia em treinamento de profissionais para rea de TI.
Visando a mxima qualidade, a K19 mantm as suas apostilas em constante renovao e melho-
ria, oferece instalaes fsicas apropriadas para o ensino e seus instrutores esto sempre atualizados
didtica e tecnicamente.
www.facebook.com/k19treinamentos 1
S UMRIO 2
Seguro Treinamento
Na K19 o aluno faz o curso quantas vezes quiser!
Comprometida com o aprendizado e com a satisfao dos seus alunos, a K19 a nica que pos-
sui o Seguro Treinamento. Ao contratar um curso, o aluno poder refaz-lo quantas vezes desejar
mediante a disponibilidade de vagas e pagamento da franquia do Seguro Treinamento.
As vagas no preenchidas at um dia antes do incio de uma turma da K19 sero destinadas ao
alunos que desejam utilizar o Seguro Treinamento. O valor da franquia para utilizar o Seguro Treina-
mento 10% do valor total do curso.
2 www.k19.com.br
3 S UMRIO
Termo de Uso
Termo de Uso
Todo o contedo desta apostila propriedade da K19 Treinamentos. A apostila pode ser utilizada
livremente para estudo pessoal . Alm disso, este material didtico pode ser utilizado como material
de apoio em cursos de ensino superior desde que a instituio correspondente seja reconhecida pelo
MEC (Ministrio da Educao) e que a K19 seja citada explicitamente como proprietria do material.
proibida qualquer utilizao desse material que no se enquadre nas condies acima sem
o prvio consentimento formal, por escrito, da K19 Treinamentos. O uso indevido est sujeito s
medidas legais cabveis.
www.facebook.com/k19treinamentos 3
S UMRIO 4
TR
EIN
AM
EN
TR
TO
EIN
S
TREINAMENTOS
AM
EN
TO
S
Conhea os nossos cursos
www.k19.com.br/cursos
4 www.k19.com.br
CAPTULO
I NTRODUO
1
Sistemas Corporativos
Dificilmente, uma empresa consegue sobreviver sem auxlio de ferramentas computacionais. Al-
gumas organizaes necessitam de ferramentas bsicas como editores de texto, planilhas ou gerado-
res de apresentao enquanto outras necessitam de ferramentas especficas (sistemas corporativos)
que contemplem todos os processos administrativos da organizao.
Orientao a Objetos
Modularidade
Encapsulamento
Polimorfismo
Padres de Projeto
www.facebook.com/k19treinamentos 5
I NTRODUO 6
Para no perder tempo e dinheiro elaborando solues diferentes para o mesmo problema, po-
deramos escolher uma soluo como padro e adot-la toda vez que o problema correspondente
ocorrer. Alm de evitar o retrabalho, facilitaramos a comunicao dos desenvolvedores e o entendi-
mento tcnico do sistema.
A referncia mais importante relacionada a padres de projeto o livro Design Patterns: Elements
of Reusable Object-Oriented Software (editora Addison-Wesley, 1995) dos autores Erich Gamma, Ri-
chard Helm, Ralph Johnson e John Vlissides. Esses quatro autores so conhecidos como Gang of
Four(GoF). Os diagramas UML apresentados nesta apostila so baseados nos diagramas desse livro.
Padres GoF
Os padres definidos no livro Design Patterns: Elements of Reusable Object-Oriented Software so
denominados padres GoF. Eles so classificados em trs categorias: padres de criao, estruturais
e comportamentais.
6 www.k19.com.br
CAPTULO
PADRES DE CRIAO
2
Em um sistema orientado a objetos, a criao de certos objetos pode ser uma tarefa extrema-
mente complexa. Podemos destacar dois problemas relacionados a criao de objetos:
definir qual classe concreta deve ser utilizada para criar o objeto;
definir como os objetos devem ser criados e como eles se relacionam com outros objetos do
sistema.
Seguindo o princpio do encapsulamento, essa complexidade deve ser isolada. A seguir, mostra-
remos padres de projetos que podem ser adotados para encapsular a criao de objetos em diversas
situaes distintas.
Factory Method Encapsular a escolha da classe concreta a ser utilizada na criao de objetos de um
determinado tipo.
Abstract Factory Encapsular a escolha das classes concretas a serem utilizadas na criao dos obje-
tos de diversas famlias.
Builder Separar o processo de construo de um objeto de sua representao e permitir a sua cri-
ao passo-a-passo. Diferentes tipos de objetos podem ser criados com implementaes dis-
tintas de cada passo.
Singleton Permitir a criao de uma nica instncia de uma classe e fornecer um modo para recuper-
la.
Multiton Permitir a criao de uma quantidade limitada de instncias de determinada classe e for-
necer um modo para recuper-las.
Factory Method
Objetivo: Encapsular a escolha da classe concreta a ser utilizada na criao de objetos de um de-
terminado tipo.
www.facebook.com/k19treinamentos 7
PADRES DE CRIAO 8
Exemplo prtico
Considere um sistema bancrio que precisa enviar mensagens aos seus clientes. Por exemplo,
aps a realizao de uma compra com carto de crdito, uma mensagem contendo informaes
sobre a compra pode ser enviada ao cliente.
Se esse cliente for uma pessoa fsica, poder optar pelo recebimento da mensagem atravs de
email ou SMS. Por outro lado, se for uma pessoa jurdica, poder tambm receber a mensagem atra-
vs de JMS (Java Message Service).
K19 Kard
K19
Data:
10/12/2011
Valor:
DEBIT
R$ 300,00
Transao
Aprovada
Cada mecanismo de envio ser implementado por uma classe. Podemos criar uma interface para
padronizar essas classes e obter polimorfismo entre seus objetos.
8 www.k19.com.br
9 PADRES DE CRIAO
Quando for necessrio enviar um mensagem, podemos utilizar diretamente esses emissores.
Utilizando essa abordagem, o cdigo que deseja enviar uma mensagem referencia diretamente
as classes que implementam os mecanismos de envio. Para eliminar essa referncia direta, podemos
adicionar um intermedirio entre o cdigo que deseja enviar uma mensagem e as classes que imple-
mentam os emissores. Esse intermedirio ser o responsvel pela escolha da classe concreta a ser
utilizada para criar o tipo de emissor adequado.
Especializao
Talvez, o sistema tenha que trabalhar com dois tipos diferentes de envio de mensagens: sncrono
e assncrono. Podemos especializar o criador de emissores, definindo subclasses.
www.facebook.com/k19treinamentos 9
PADRES DE CRIAO 10
Agora, para enviar uma mensagem, podemos acionar o criador adequado (EmissorCreator,
EmissorAssincronoCreator ou EmissorSincronoCreator) para obter o emissor desejado.
Organizao
10 www.k19.com.br
11 PADRES DE CRIAO
Client
<<usa>> <<usa>>
Product Creator
factoryMethod()
ConcreteProduct ConcreteCreator
<<cria>> factoryMethod()
Product (Emissor)
Classe ou interface que define o objeto a ser criado.
ConcreteProduct (EmissorSMS)
Uma implementao particular do tipo de objeto a ser criado.
Creator (EmissorCreator)
Classe ou interface que define a assinatura do mtodo responsvel pela criao do produto.
Pode possuir uma implementao padro do mtodo de criao do produto.
ConcreteCreator (EmissorAssincronoCreator)
Classe que implementa ou sobrescreve o mtodo de criao do produto.
Exerccios de Fixao
www.facebook.com/k19treinamentos 11
PADRES DE CRIAO 12
5 Para tornar a classe TestaEmissores menos dependente das classes que implementam os me-
canismos de envio, podemos definir uma classe intermediria que ser responsvel pela criao dos
emissores.
12 www.k19.com.br
13 PADRES DE CRIAO
15 }
16 }
17 }
Abstract Factory
Objetivo: Encapsular a escolha das classes concretas a serem utilizadas na criao dos objetos de
diversas famlias.
Exemplo prtico
Pagamentos com cartes so realizados por meio de uma mquina de carto, oferecida e insta-
lada por empresas como Cielo e Redecard. Geralmente, essa mquina capaz de lidar com cartes
de diferentes bandeiras (como Visa e Mastercard).
Nosso objetivo programar essas mquinas, isto , desenvolver uma aplicao capaz de se co-
municar com as diferentes bandeiras e registrar pagamentos.
www.facebook.com/k19treinamentos 13
PADRES DE CRIAO 14
DEBIT
O nosso sistema ser composto por objetos emissores e receptores de mensagens. Como o pro-
tocolo de comunicao de cada bandeira diferente. Como cada bandeira possui o seu prprio
protocolo de comunicao, teremos um emissor e um receptor para cada bandeira.
Criaremos fbricas especficas para cada bandeira. Essas fbricas sero responsveis pela criao
dos emissores e receptores. Para padroniz-las, podemos criar uma interface.
14 www.k19.com.br
15 PADRES DE CRIAO
Organizao
www.facebook.com/k19treinamentos 15
PADRES DE CRIAO 16
AbstractFactory <<usa>>
createProductA() Client
createProductB() <<usa>>
AbstractProductA
ConcreteProductA1 ConcreteProductA2
ConcreteProductB1 ConcreteProductB2
<<cria>>
AbstractFactory (ComunicadorFactory)
Interface que define as assinaturas dos mtodos responsveis pela criao dos objetos uma
famlia.
Client (Aplicao)
Usa apenas as interfaces AbstractFactory e AbstractProduct.
16 www.k19.com.br
17 PADRES DE CRIAO
Exerccios de Fixao
www.facebook.com/k19treinamentos 17
PADRES DE CRIAO 18
7 }
18 www.k19.com.br
19 PADRES DE CRIAO
www.facebook.com/k19treinamentos 19
PADRES DE CRIAO 20
Exerccios Complementares
Builder
Exemplo prtico
Estamos desenvolvendo um sistema para gerar boletos bancrios. No Brasil, a FEBRABAN (Fede-
rao Brasileira de Bancos) define regras gerais para os boletos. Contudo, cada instituio bancria
define tambm as suas prprias regras especficas para o formato dos dados dos boletos.
Banco: Instituio que receber o pagamento do sacado e creditar o valor na conta do cedente.
Nosso Nmero: Cdigo de identificao do boleto utilizado pela instituio bancria e pelo cedente
para controle dos pagamentos.
20 www.k19.com.br
21 PADRES DE CRIAO
Valor
Sacado
Vencimento
K19 Treinamentos
Valor
Sacado
Vencimento
Rafael Cosentino
Para gerar um boleto, devemos definir todas essas informaes. Para encapsular a complexidade
desse processo, poderamos definir classes responsveis pela criao dos boletos de acordo com a
instituio bancria. Inclusive, poderamos padronizar essas classes atravs de uma interface.
www.facebook.com/k19treinamentos 21
PADRES DE CRIAO 22
7 void buildCodigoDeBarras () ;
8 void buildLogotipo () ;
9
10 Boleto getBoleto () ;
11 }
Agora, poderamos obter de alguma fonte externa (usurio, banco de dados, arquivos e etc) as
informaes necessrias e gerar um boleto utilizando o montador adequado.
Quando for necessrio gerar um boleto, devemos escolher uma implementao da interface
BoletoBuilder.
22 www.k19.com.br
23 PADRES DE CRIAO
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
<<interface>>
Director Builder
construct() buildPartA()
buildPartB()
Product
<<usa>>
ConcreteBuilder1 ConcreteBuilder2
Client <<cria>>
buildPartA() buildPartA() Product2 Product1
buildPartB() buildPartB()
<<cria>>
Product (Boleto)
Define os objetos que devem ser construdos pelos Builders.
Builder (BoletoBuilder)
Interface que define os passos para a criao de um produto.
Director (GeradorDeBoleto)
Aciona os mtodo de um Builder para construir um produto.
Exerccios de Fixao
www.facebook.com/k19treinamentos 23
PADRES DE CRIAO 24
6 int getNossoNumero () ;
7 String toString () ;
8 }
24 www.k19.com.br
25 PADRES DE CRIAO
18 Defina uma interface que ir padronizar as classes responsveis pela criao dos boletos.
www.facebook.com/k19treinamentos 25
PADRES DE CRIAO 26
Prototype
Exemplo prtico
Estamos desenvolvendo um sistema de anncios semelhante ao do Google Adwords. Nesse sis-
tema, os usurios podero criar campanhas e configur-las de acordo com as suas necessidades.
Uma campanha composta por diversas informaes, entre elas:
26 www.k19.com.br
27 PADRES DE CRIAO
Nesse tipo de sistema, os usurios geralmente criam campanhas com configuraes extrema-
mente parecidas. Dessa forma, seria interessante que o sistema tivesse a capacidade de criar uma
campanha a partir de uma outra campanha j criada anteriormente, para que as configuraes pu-
dessem ser aproveitadas.
Vrios objetos do nosso sistema poderiam ter essa capacidade. Seria interessante definir uma
interface para padronizar e marcar os objetos com essas caractersticas.
Depois, devemos implementar a interface Prototype nas classes que devem possuir a caracte-
rstica que desejamos.
Quando o usurio quiser criar uma campanha com as mesmas configuraes de uma campanha
j criada, devemos escrever um cdigo semelhante a este:
www.facebook.com/k19treinamentos 27
PADRES DE CRIAO 28
Organizao
Prototype <<usa>>
Client
clone()
ConcretePrototype1 ConcretePrototype2
clone() clone()
Prototype
Abstrao dos objetos que possuem a capacidade de se auto copiar.
ConcretePrototype (Campanha)
Classe que define um tipo particular de objeto que pode ser clonado.
Client
Classe que cria novos objetos a partir da interface definida por Prototype.
Exerccios de Fixao
28 www.k19.com.br
29 PADRES DE CRIAO
www.facebook.com/k19treinamentos 29
PADRES DE CRIAO 30
Singleton
Objetivo: Permitir a criao de uma nica instncia de uma classe e fornecer um modo para
recuper-la.
Exemplo prtico
Suponha que estamos desenvolvendo um sistema que possui configuraes globais obtidas a
partir de um arquivo de propriedades. Essas configuraes podem ser armazenadas em um objeto.
No desejamos que existam mais do que um objeto dessa classe ao mesmo tempo no sistema.
Para garantir essa restrio, podemos tornar o construtor da classe Configuracao privado e imple-
mentar um mtodo esttico que controle a criao do nico objeto que deve existir.
De qualquer ponto do cdigo do nosso sistema, podemos acessar o objeto que contm as confi-
guraes da aplicao.
30 www.k19.com.br
31 PADRES DE CRIAO
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
<<usa>> Singleton
Client
static getInstance()
Singleton (Configuracao)
Classe que permite a criao de uma nica instncia e fornece um mtodo esttico para recuper-
la.
Exerccios de Fixao
27 Crie a classe Configurao e impea que mais de um objeto exista ao mesmo tempo no sistema.
www.facebook.com/k19treinamentos 31
PADRES DE CRIAO 32
Exemplo prtico
Estamos desenvolvendo uma aplicao que possuir diversos temas para interface do usurio. O
nmero de temas limitado e cada usurio poder escolher o de sua preferncia. Podemos imple-
mentar os temas atravs de uma classe.
Agora, devemos criar os temas que sero disponibilizados para a escolha dos usurios.
O construtor da classe Tema deve ser privado para que os objetos no sejam criados em qualquer
lugar da aplicao. Alm disso, essa classe deve disponibilizar um mtodo para que as instncias
possam ser acessadas globalmente.
32 www.k19.com.br
33 PADRES DE CRIAO
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
Multiton
<<usa>>
Client
static getInstance(id)
Multiton (Tema)
Classe que permite a criao de uma quantidade limitada de instncias e fornece um mtodo
esttico para recuper-las.
Exerccios de Fixao
30 Crie a classe Tema e pr defina os temas Fire e Sky utilizando o padro Multiton.
www.facebook.com/k19treinamentos 33
PADRES DE CRIAO 34
34 www.k19.com.br
35 PADRES DE CRIAO
Considere a seguinte situao. Pretendemos ir a um restaurante sem ter, contudo, efetuado uma
reserva. Ao chegar no restaurante, podemos nos deparar com duas situaes: (i) h pelo menos uma
mesa livre e podemos nos sentar ou (ii) todas as mesas esto ocupadas e precisamos esperar at que
uma mesa seja liberada.
www.facebook.com/k19treinamentos 35
PADRES DE CRIAO 36
RECEPO
RECEPO
RECEPO
Essa uma situao tpica em que recursos limitados devem ser reutilizados. O restaurante no
adquire novas mesas a medida que clientes chegam ao restaurante e as mesas so reutilizadas por
novos clientes assim que so liberadas.
Exemplo prtico
Estamos desenvolvendo um sistema para uma empresa com uma quantidade muito grande de
projetos. Esse sistema deve controlar os recursos utilizados nos projetos. De maneira genrica, um
recurso pode ser um funcionrio, uma sala, um computador, um carro, etc.
Podemos implementar classes especializadas no controle de cada tipo de recurso utilizado nos
projetos. Alm disso, seria interessante padronizar essas classes atravs de uma interface.
36 www.k19.com.br
37 PADRES DE CRIAO
2 T acquire () ;
3 void release ( T t ) ;
4 }
Agora, quando um projeto necessita de um recurso como funcionrios ou salas basta utilizar os
pools.
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
www.facebook.com/k19treinamentos 37
PADRES DE CRIAO 38
<<usa>> Pool
Client
acquire()
release()
ConcretePool1 ConcretePool2
acquire() acquire()
release() release()
Product1 Product2
Pool (Pool)
Interface dos objetos que controlam a aquisio e a liberao dos Products.
Exerccios de Fixao
38 www.k19.com.br
39 PADRES DE CRIAO
www.facebook.com/k19treinamentos 39
PADRES DE CRIAO 40
40 www.k19.com.br
CAPTULO
PADRES E STRUTURAIS
3
As interaes entre os objetos de um sistema podem gerar fortes dependncias entre esses ele-
mentos. Essas dependncias aumentam a complexidade das eventuais alteraes no funcionamento
do sistema. Consequentemente, o custo de manuteno aumenta. Mostraremos alguns padres de
projeto que diminuem o acoplamento entre os objetos de um sistema orientado a objetos.
Adapter Permitir que um objeto seja substitudo por outro que, apesar de realizar a mesma tarefa,
possui uma interface diferente.
Bridge Separar uma abstrao de sua representao, de forma que ambos possam variar e produzir
tipos de objetos diferentes.
Composite Agrupar objetos que fazem parte de uma relao parte-todo de forma a trat-los sem
distino.
Facade Prover uma interface simplificada para a utilizao de vrias interfaces de um subsistema.
Adapter
Objetivo: Permitir que um objeto seja substitudo por outro que, apesar de realizar a mesma tarefa,
possui uma interface diferente.
No Brasil, mais de dez tipos de tomadas e plugues eram comercializados. Em 2007, um novo
padro para os plugues e tomadas foi definido pela ABNT. Em 2011, tornou-se permitida somente a
venda de produtos que seguiam o novo padro de dois ou trs pinos redondos.
No entanto, muitos consumidores ainda no esto preparados para o novo padro e possuem
tomadas incompatveis principalmente com os plugues de trs pinos.
Por outro lado, h tambm os casos em que a tomada segue o novo padro mas o plugue do
aparelho no o segue. Esse pode ser o caso de aparelhos adquiridos antes da nova lei entrar em vigor
ou adquiridos fora do Brasil.
www.facebook.com/k19treinamentos 41
PADRES E STRUTURAIS 42
Exemplo prtico
Uma empresa parceira implementou uma biblioteca Java para controlar a entrada e sada dos
funcionrios. Essa biblioteca no possui as limitaes que existem hoje no sistema que estamos
realizando manuteno. Os diretores decidiram que a melhor estratgia seria adquirir essa biblioteca
e implant-la no sistema.
Para implantar essa biblioteca, teremos que substituir as classes que atualmente cuidam do con-
trole de ponto pelas classes dessa biblioteca. A complexidade dessa substituio alta pois os mto-
dos das classes antigas no so compatveis com os mtodos das classes novas. Em outras palavras,
as interfaces so diferentes.
42 www.k19.com.br
43 PADRES E STRUTURAIS
Para tentar minimizar o impacto dessa substituio no cdigo do sistema, podemos definir clas-
ses intermedirias para adaptar as chamadas s classes da biblioteca que foi adquirida.
Utilizando as classes da nova biblioteca, a entrada de um funcionrio deveria ser registrada as-
sim:
Dessa forma, o cdigo do sistema atual deve ser modificado apenas no trecho em que a classe
responsvel pelo controle de ponto instanciada.
Organizao
www.facebook.com/k19treinamentos 43
PADRES E STRUTURAIS 44
<<usa>>
Target
Client
request()
Adapter Adaptee
request() specificRequest()
Target (ControleDePonto)
Define a interface utilizada pelo Client.
Adaptee (ControleDePontoNovo)
Classe que define o novo objeto a ser utilizado.
Adapter (ControleDePontoAdapter)
Classe que implementa a interface definida pelo Target e adapta as chamadas do Client para
o Adaptee.
Client
Interage com os objetos atravs da interface definida por Target.
Exerccios de Fixao
44 www.k19.com.br
45 PADRES E STRUTURAIS
www.facebook.com/k19treinamentos 45
PADRES E STRUTURAIS 46
6 }
7
8 public void registraEntrada ( Funcionario f ) {
9 this . controleDePontoNovo . registra (f , true ) ;
10 }
11
12 public void registraSaida ( Funcionario f ) {
13 this . controleDePontoNovo . registra (f , false ) ;
14 }
15 }
Bridge
Objetivo: Separar uma abstrao de sua representao, de forma que ambos possam variar e pro-
duzir tipos de objetos diferentes.
Hoje em dia, os celulares utilizam cartes SIM (subscriber identity module). Entre outros dados,
esses cartes armazenam o nmero do telefone, a chave de autenticao do cliente e um identifica-
dor da rede a ser usada na comunicao.
Antes de ser capaz de fazer ligaes, o celular precisa passar pelo processo de autenticao. Nesse
processo, o celular troca informaes com a rede mvel a fim de verificar a identidade do usurio.
Alm de armazenar toda informao necessria para essa autenticao, o carto SIM quem de
fato executa os algoritmos de criptografia usados nesse processo, e no o aparelho celular. Uma vez
que a autenticao feita, o celular torna-se capaz de fazer ligaes.
A maioria dos celulares disponveis hoje em dia capaz de lidar com diversas operadoras, bas-
tando apenas que o carto SIM do celular seja substitudo. Essa uma das vantagens dessa tecnolo-
gia.
Se o seu aparelho celular estiver danificado ou sem bateria, voc pode simplesmente remover
o carto SIM do aparelho e coloc-lo em outro. Por outro lado, se voc viajar para outro pas, por
exemplo, voc pode levar o seu aparelho celular e adquirir um carto SIM de uma operadora local.
46 www.k19.com.br
47 PADRES E STRUTURAIS
3G 4:08 PM
# @
Q
1
w
2 3 ( ) _ - 0
+
P
E R Y U I
T
*A 4 5 6 / : ; , del
S D F G H J K L
alt 7
Z
8 9 ? ! , . $
X C V B N M
aA
0 space sym aA
Exemplo prtico
Estamos desenvolvendo um sistema que deve gerar diversos tipos de documentos (recibos, ates-
tados, comunicados, etc) em diversos formatos de arquivos (txt, html, pdf, etc).
Podemos definir uma interface para padronizar os diversos tipos de documentos que o nosso
sistema pode suportar.
www.facebook.com/k19treinamentos 47
PADRES E STRUTURAIS 48
Dessa forma, a lgica dos documentos seria definida nas classes que implementam a interface
Documento. Para dividir melhor as responsabilidades, podemos implementar a lgica dos formatos
de arquivos que o sistema suportar em outras classes. Inclusive, podemos definir uma interface
para padronizar essas classes.
Por fim, os documentos devem ser associados aos geradores de arquivos. Isso pode ser realizado
atravs de construtores nas classes especficas de documentos.
48 www.k19.com.br
49 PADRES E STRUTURAIS
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
operationImpl() operationImpl()
Abstraction (Documento)
Define a interface de um determinado tipo de objeto.
RefinedAbstraction (Recibo)
Uma implementao particular do Abstraction que delega a um Implementor a realizao de
determindas tarefas.
Implementor (GeradorDeArquivo)
Define a interface dos objetos que sero acionados pelos Abstractions.
Client
Interage com as Abstractions.
Exerccios de Fixao
www.facebook.com/k19treinamentos 49
PADRES E STRUTURAIS 50
12 A classe Recibo somente gera arquivo no formato txt. Para suportar mais formatos, podemos
definir a lgica de gerar arquivos em diversos formatos em outras classes. Vamos padronizar estas
classes atravs de uma interface.
50 www.k19.com.br
51 PADRES E STRUTURAIS
3 try {
4 PrintStream saida = new PrintStream ( " arquivo . txt " ) ;
5 saida . println ( conteudo ) ;
6 saida . close () ;
7 } catch ( FileNotFoundException e ) {
8 e . printStackTrace () ;
9 }
10 }
11 }
14 Associe os geradores de arquivos aos documentos. Altere a classe Recibo para receber um gera-
dor de arquivo como parmetro no construtor.
Composite
www.facebook.com/k19treinamentos 51
PADRES E STRUTURAIS 52
Objetivo: Agrupar objetos que fazem parte de uma relao parte-todo de forma a trat-los sem
distino.
Exemplo prtico
Suponha que estamos desenvolvendo um sistema para calcular um caminho entre quaisquer
dois pontos do mundo. Um caminho pode ser percorrido de diversas maneiras: p, de carro, de
nibus, de trem, de avio, de navio, etc.
52 www.k19.com.br
53 PADRES E STRUTURAIS
Avio nibus
Txi Metr
C
Natal - RN K19
T A O C
Natal - RN NAT NAT GRU GRU TIET TIET K19
M P
LEGENDA TIET FARIA LIMA FARIA LIMA K19
C Caminho
T Txi
A Avio
O nibus
M Metr
P p
www.facebook.com/k19treinamentos 53
PADRES E STRUTURAIS 54
O sistema deve apresentar graficamente para os usurios as rotas que forem calculadas. Cada
tipo de trecho deve ser apresentado de uma maneira especfica. Por exemplo, se o trecho for de
caminhada ento deve aparecer na impresso da rota a ilustrao de uma pessoa andando.
Cada tipo de trecho pode ser implementado por uma classe e seria interessante definir uma in-
terface para padroniz-las.
O prprio caminho entre dois pontos pode ser considerado um trecho. Basicamente, um cami-
nho um trecho composto por outros trechos.
54 www.k19.com.br
55 PADRES E STRUTURAIS
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
<<interface>>
Component
operation()
Leaf Composite
operation() operation()
add()
remove()
Component (Trecho)
Interface que define os elementos da composio.
Composite (Caminho)
Define os Components que so formados por outros Components.
Exerccios de Fixao
www.facebook.com/k19treinamentos 55
PADRES E STRUTURAIS 56
19 Defina uma classe Caminho que um Trecho e ser composto por um ou mais trechos.
56 www.k19.com.br
57 PADRES E STRUTURAIS
20 Crie uma classe para testar e criar um caminho que composto por mais de um trecho.
Decorator
Considere um mapa de ruas digital, como o Google Maps, por exemplo. natural que o mapa
contenha os nomes das ruas. Contudo, o mapa tambm poderia exibir diversas outras informaes
(como, por exemplo, relevo, indicadores de estabelecimentos de comrcio e servio), bem como ofe-
recer opes para encontrar caminhos entre dois pontos e traar rotas.
www.facebook.com/k19treinamentos 57
PADRES E STRUTURAIS 58
100m
Rua
Tav
are
sC
abr
al
Av. Rebouas
100m
Rua
Tav
are
sC $
abr
al
Av. Brigadeiro Faria Lima
R. Henrique Monteiro
Av.
Eus
bio
Ma
tos
o
Av. Rebouas
Av. Rebouas
K19
100m
Rua
Tav
are
sC $
_ abr
al
Av. Brigadeiro Faria Lima
R. Henrique Monteiro
Av.
Eus
bio
Ma
tos
o
Av. Rebouas
Av. Rebouas
K19
100m
58 www.k19.com.br
59 PADRES E STRUTURAIS
Exemplo prtico
Como exemplo prtico do padro Factory Method, consideramos um sistema de envio de men-
sagens. Nesse exemplo, definimos uma interface para padronizar os emissores.
Para no alterar as classes que definem os emissores, cada funcionalidade adicional (decorao)
ser implementada por um novo objeto (decorador).
Quando queremos enviar uma mensagem, no podemos chamar diretamente os emissores, pois
as funcionalidades adicionais no sero executadas. Portanto, devemos entregar a mensagem a um
decorador, que executar a tarefa para a qual foi concebido. O decorador, por sua vez, ter tambm
a responsabilidade de repassar a mensagem a um emissor para que ela seja enviada. Dessa forma,
todo decorador deve possuir um emissor.
O cdigo atual utiliza a interface dos emissores para enviar mensagens. Para no afetar esse
cdigo, os decoradores devem seguir a mesma interface dos emissores. Assim, quem envia uma
mensagem atravs de um emissor, no sabe se este emissor um decorador. Note que, dessa forma,
decoradores podem ser encadeados.
Vamos ento definir uma classe abstrata para representar os decoradores de emissores. Nesta
classe, definiremos que todos os decoradores possuiro um emissor.
www.facebook.com/k19treinamentos 59
PADRES E STRUTURAIS 60
Organizao
60 www.k19.com.br
61 PADRES E STRUTURAIS
<<interface>>
Component
operation()
ConcretComponent Decorator
operation() operation()
ConcreteDecoratorA ConcreteDecoratorB
operation() operation()
Component (Emissor)
Define a interface de objetos que possuem determinada tarefa.
ConcreteComponent (EmissorBasico)
Implementao particular do Component.
Decorator (EmissorDecorator)
Classe abstrata que mantm uma referncia para um Component e ser utilizada para padroni-
zar os objetos decoradores.
Exerccios de Fixao
www.facebook.com/k19treinamentos 61
PADRES E STRUTURAIS 62
25 Crie um decorador que envia mensagens criptografadas e outro que envia mensagens compri-
midas.
62 www.k19.com.br
63 PADRES E STRUTURAIS
14 }
15 this . getEmissor () . envia ( mensagemComprimida ) ;
16 }
17
18 private String comprime ( String mensagem ) throws IOException {
19 ByteArrayOutputStream out = new ByteArrayOutputStream () ;
20 DeflaterOutputStream dout = new DeflaterOutputStream ( out , new Deflater () ) ;
21 dout . write ( mensagem . getBytes () ) ;
22 dout . close () ;
23 return new String ( out . toByteArray () ) ;
24 }
25 }
26 Teste os decoradores.
Facade
Objetivo: Prover uma interface simplificada para a utilizao de vrias interfaces de um subsis-
tema.
Considere uma pessoa planejando suas prximas frias de vero. Ela poderia comprar a passa-
gem area, reservar o hotel e agendar passeios, tudo por conta prpria.
Entretanto, tudo isso poderia ser muito trabalhoso. Em particular, ela precisaria pesquisar pre-
os, comparar opes, reservar o hotel de acordo com as datas de chegada e sada de seu voo, etc.
nesse ponto que entram as agncias de viagens. Elas podem facilitar essa tarefa e trazer como-
didade quele que deseja viajar, atuando como um intermedirio entre o cliente e as companhias
areas, hotis e empresas de passeio.
www.facebook.com/k19treinamentos 63
PADRES E STRUTURAIS 64
K19 Viagens
Figura 3.9: Pessoa comprando um pacote oferecido por uma agncia de viagens
Exemplo prtico
Estamos melhorando um sistema que realiza todos os procedimentos que devem ser realizados
aps o registro de um pedido. Quando um pedido realizado, o mdulo que gerencia o estoque deve
ser avisado para que o produto seja encaminhado ao endereo de entrega. O mdulo financeiro deve
ser avisado para que o processo de faturamento seja realizado. O mdulo de ps venda tambm
deve ser avisado para que contatos futuros sejam realizados com o cliente com o intuito de verificar
a satisfao do mesmo com o produto obtido.
1 Pedido p = ...
2 estoque . enviaProduto ( p . getProduto () , p . getEnderecoDeEntrega () , p . getNotaFiscal () ) ;
3 finaceiro . fatura ( p . getCliente () , p . getNotaFiscal () ) ;
4 posVenda . agendaContato ( p . getCliente () , p . getProduto () ) ;
A ideia aqui criar uma classe que encapsula todos os processos que envolvem o acesso aos
mdulos de estoque, financeiro e de ps venda.
64 www.k19.com.br
65 PADRES E STRUTURAIS
3
4 private Financeiro financeiro ;
5
6 private PosVenda posVenda ;
7
8 public PedidoFacade ( Estoque estoque , Financeiro financeiro , PosVenda posVenda ) {
9 this . estoque = estoque ;
10 this . financeiro = financeiro ;
11 this . posVenda = posVenda ;
12 }
13
14 public void registraPedido ( Pedido p ) {
15 this . estoque . enviaProduto ( p . getProduto () , p . getEnderecoDeEntrega () , p . -
getNotaFiscal () ) ;
16 this . financeiro . fatura ( p . getCliente () , p . getNotaFiscal () ) ;
17 this . posVenda . agendaContato ( p . getCliente () , p . getProduto () ) ;
18 }
19
20 public void cancelaPedido ( Pedido p ) {
21 // logica para cancelar pedidos
22 }
23 }
1 Pedido p = ...
2 PedidoFacade pedidoFacade = ...
3 pedidoFacade . registraPedido ( p ) ;
1 Pedido p = ...
2 PedidoFacade pedidoFacade = ...
3 pedidoFacade . cancelaPedido ( p ) ;
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
ComponentA
<<usa>> <<usa>>
Client Facade ComponentB
ComponentC
www.facebook.com/k19treinamentos 65
PADRES E STRUTURAIS 66
Client
Classe que usa os Component de forma indireta atravs do Facade.
Exerccios de Fixao
66 www.k19.com.br
67 PADRES E STRUTURAIS
29 Crie uma classe PedidoFacade que encapsula o acesso aos mdulos de estoque, financeiro e ps
venda.
www.facebook.com/k19treinamentos 67
PADRES E STRUTURAIS 68
Exemplo prtico
Estamos desenvolvendo um framework MVC para o desenvolvimento de aplicaes web em Java.
O processamento de uma requisio HTTP segue os seguintes passos:
O nosso framework deve interceptar todas as requisies HTTP para realizar esses passos. Para
interceptar as requisies HTTP, podemos implementar uma Servlet.
As tarefas que devem ser realizadas em todas as requisies podem ser implementadas nessa
Servlet. Por outro lado, as tarefas especficas devem ser delegadas para outra parte do framework ou
para a aplicao.
Aplicao WEB
Requisio HTTP
Lgica de
Negcio
FRONT
CONTROLLER
Lgica de
Apresentao
Resposta HTTP
- Segurana
- Controle de erro
68 www.k19.com.br
69 PADRES E STRUTURAIS
Exerccios de Fixao
1 package controllers ;
2
3 import java . io . IOException ;
4 import java . lang . reflect . Method ;
5
6 import javax . servlet . RequestDispatcher ;
7 import javax . servlet . ServletException ;
8 import javax . servlet . annotation . WebServlet ;
9 import javax . servlet . http . HttpServlet ;
10 import javax . servlet . http . HttpServletRequest ;
11 import javax . servlet . http . HttpServletResponse ;
12
13 @WebServlet ( " *. k19 " )
14 public class FrontController extends HttpServlet {
15 private static final long serialVersionUID = 1 L ;
16
17 public void service ( HttpServletRequest req , HttpServletResponse res )
18 throws ServletException , IOException {
19 String [] split = req . getRequestURI () . split ( " / " ) ;
20
21 String controllerName = split [2];
22 String actionName = split [3]. split ( " \\. " ) [0];
23
24 System . out . println ( controllerName ) ;
25 System . out . println ( actionName ) ;
26
27 try {
28
29 Class <? > controllerClass = Class . forName ( " controllers . "
30 + controllerName ) ;
31 Method method = controllerClass . getDeclaredMethod ( actionName ) ;
32
33 Object controller = controllerClass . newInstance () ;
34 method . invoke ( controller ) ;
35
36 RequestDispatcher dispatcher = req . getRequestDispatcher ( " / " + controllerName
37 + " / " + actionName + " . jsp " ) ;
38
39 dispatcher . forward ( req , res ) ;
40 } catch ( Exception e ) {
41 e . printStackTrace () ;
42 }
43 }
44 }
www.facebook.com/k19treinamentos 69
PADRES E STRUTURAIS 70
1 package controllers ;
2
3 public class Teste {
4 public void teste () {
5 System . out . println ( " Teste . teste () " ) ;
6 }
7 }
http://localhost:8080/FrontController/Teste/teste.k19
Flyweight
Exemplo prtico
Estamos desenvolvendo uma aplicao para gerenciar milhares de apresentaes com slides.
Essa aplicao disponibilizar um conjunto de temas que podem ser aplicados individualmente em
cada slide de uma apresentao.
Em geral, o contedo (ttulo e texto) de cada slide nico. Portanto, no seria possvel comparti-
lhar de maneira eficiente o contedo de slides diferentes.
Por outro lado, como vrios slides podem utilizar o mesmo tema, eles poderiam compartilhar
as informaes relativas formatao da fonte, cor de fundo, layout, e etc. Consequentemente, a
quantidade de memria utilizada seria drasticamente reduzida.
70 www.k19.com.br
71 PADRES E STRUTURAIS
Sigla: K11
K11 - Orientao a Objetos em Java
Nome: Orientao a Objetos em Java
Carga horria: 36h
Carga Horria: 36h
Sigla: K12
Nome: Desenvolvimento Web com K12 - Desenvovimento Web com
JSF2 e JPA2 JSF2 e JPA2
Carga horria: 36h
Carga Horria: Carga Horria: 36h
A interface TemaFlyweight define um mtodo que recebe o contedo dos slides e deve aplicar a
formatao correspondente ao tema. Com a interface definida, podemos implementar alguns temas
especficos.
www.facebook.com/k19treinamentos 71
PADRES E STRUTURAIS 72
Para controlar a criao e acesso dos objetos que definem os temas, podemos implementar a
seguinte classe.
Por fim, deveramos associar os slides aos temas. Isso poderia ser feito atravs do construtor da
classe que define os slides.
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
<<interface>>
FlyweightFactory Flyweight
getFlyweight(id)
operation()
ConcreteFlyweight1 ConcreteFlyweight1
operation() operation()
<<usa>>
Client
72 www.k19.com.br
73 PADRES E STRUTURAIS
Flyweight (TemaFlyweight)
Interface que define os objetos que sero compartilhados.
FlyweightFactory (TemaFlyweightFactory)
Classe que controla a criao e recuperao de Flyweights.
Client
Utiliza FlyweightFactory para recuperar os Flyweights.
Exerccios de Fixao
www.facebook.com/k19treinamentos 73
PADRES E STRUTURAIS 74
74 www.k19.com.br
75 PADRES E STRUTURAIS
Proxy
Para isso, o computador deve estar conectado ao no-break e no tomada. O no-break, por sua
vez, deve estar conectado tomada.
www.facebook.com/k19treinamentos 75
PADRES E STRUTURAIS 76
Essa a mesma ideia do padro Proxy. Esse padro define um intermedirio para controlar o
acesso a um determinado objeto, podendo adicionar funcionalidades que esse objeto no possui.
Exemplo prtico
Estamos desenvolvendo uma aplicao bancria que deve registrar todas as operaes realiza-
das pelos objetos que representam as contas do banco. O registro das operaes pode ser utilizado
posteriormente em uma auditoria.
Para manter o sistema mais coeso, no queremos implementar o registro das operaes dentro
dos objetos que representam as contas. A ideia implementar essa lgica em objetos intermedi-
rios. Para preservar o modo de utilizao das contas, podemos manter a interface nesses objetos
intermedirios.
Podemos definir uma interface para padronizar os mtodos dos objetos que representam as con-
tas e os objetos intermedirios responsveis pelo registro das operaes.
76 www.k19.com.br
77 PADRES E STRUTURAIS
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
<<interface>>
<<usa>>
Subject
Client
request()
Proxy RealSubject
request() request()
Subject (Conta)
Interface que padroniza RealSubject e Proxy.
RealSubject (ContaPadro)
Define um tipo de objeto do domnio da aplicao.
Proxy (ContaProxy)
Define os objetos que controlam o acesso aos RealSubjects.
www.facebook.com/k19treinamentos 77
PADRES E STRUTURAIS 78
Client
Cliente que usa o RealSubject por meio do Proxy.
Exerccios de Fixao
47 Crie uma classe intermediria ContaProxy que far os registros das operaes.
78 www.k19.com.br
79 PADRES E STRUTURAIS
17
18 }
19
20 public double getSaldo () {
21 System . out . println ( " Verificando o saldo ... " ) ;
22 return this . conta . getSaldo () ;
23 }
24 }
www.facebook.com/k19treinamentos 79
PADRES E STRUTURAIS 80
80 www.k19.com.br
CAPTULO
PADRES C OMPORTAMENTAIS
4
Veja abaixo um resumo do objetivo de cada padro comportamental.
Iterator Fornecer um modo eficiente para percorrer sequencialmente os elementos de uma coleo,
sem que a estrutura interna da coleo seja exposta.
Observer Definir um mecanismo eficiente para reagir s alteraes realizadas em determinados ob-
jetos.
State Alterar o comportamento de um determinado objeto de acordo com o estado no qual ele se
encontra.
Strategy Permitir de maneira simples a variao dos algoritmos utilizados na resoluo de um de-
terminado problema.
Template Method Definir a ordem na qual determinados passos devem ser realizados na resoluo
de um problema e permitir que esses passos possam ser realizados de formas diferentes de
acordo com a situao.
Visitor Permitir atualizaes especficas em uma coleo de objetos de acordo com o tipo particular
de cada objeto atualizado.
Command
Exemplo prtico
Estamos desenvolvendo um aplicativo para gerenciar playlists de msica. Os usurios podero
selecionar as suas msicas favoritas e definir a ordem na qual elas devem ser reproduzidas. Um
playlist basicamente uma sequncia de msicas. Contudo, o aplicativo pode adicionar, entre as
msicas de um playlist, comandos para aumentar ou diminuir o volume de reproduo.
Vamos utilizar uma biblioteca de udio para desenvolver esse aplicativo. Atravs dessa biblio-
teca, podemos tocar msicas e controlar o volume das sadas de udio.
www.facebook.com/k19treinamentos 81
PADRES C OMPORTAMENTAIS 82
Os trs mtodos da classe Player so bloqueantes. Por exemplo, o mtodo play() s termina
quando a msica que est sendo reproduzida terminar.
82 www.k19.com.br
83 PADRES C OMPORTAMENTAIS
Agora, devemos implementar uma classe que dispara os comandos na ordem definida pelo usu-
rio.
Por fim, teramos que criar os comandos associados a um player e depois adicion-los em um
playlist.
Organizao
www.facebook.com/k19treinamentos 83
PADRES C OMPORTAMENTAIS 84
<<interface>>
Command
Invoker
execute()
<<usa>>
ConcreteCommand1 ConcreteCommand2
<<cria>>
Client execute() execute()
Receiver
action1()
<<usa>>
action2()
<<cria>>
Command (Comando)
Define uma interface para a execuo dos mtodos do Receiver.
Invoker (ListaDeComandos)
Classe que armazena os Commands que devem ser executados.
Receiver (Player)
Define os objetos que tero as chamadas aos seus mtodos controladas.
Client
Instancia os Commands associando-os ao Receiver e armazena-os no Invoker.
Exerccios de Fixao
84 www.k19.com.br
85 PADRES C OMPORTAMENTAIS
www.facebook.com/k19treinamentos 85
PADRES C OMPORTAMENTAIS 86
5 Defina uma classe ListaDeComandos que conter a lista de comandos na ordem definida pelo
usurio.
Iterator
Objetivo: Fornecer um modo eficiente para percorrer sequencialmente os elementos de uma cole-
o, sem que a estrutura interna da coleo seja exposta.
Considere um turista que pretende visitar os principais pontos tursticos de determinada cidade.
Infelizmente, ele no pde planejar seus passeios e no sabe quais pontos tursticos existem nessa
cidade. Alm disso, seu perodo de permanncia na cidade curto.
86 www.k19.com.br
87 PADRES C OMPORTAMENTAIS
Para tornar sua experincia mais agradvel, o turista pode solicitar o servio de um guia turstico.
Guias conhecem muito bem a cidade onde atuam e sabem definir um bom roteiro para a visitao
dos pontos tursticos.
www.facebook.com/k19treinamentos 87
PADRES C OMPORTAMENTAIS 88
Exemplo prtico
A maior parte das aplicaes necessitam de estruturas de dados para organizar as informaes
armazenadas na memria. Cada estrutura estabelece um determinado conjunto de restries relaci-
onadas aos dados e disponibilizam operaes eficientes para que possamos manipular as informa-
es.
Muitas vezes, necessrio percorrer todos os elementos de uma estrutura de dados para realizar
uma determinada tarefa. A organizao interna de cada estrutura complexa e deve estar encapsu-
lada nas classes que as implementam. Dessa forma, em geral, o desenvolvedor no teria as condies
necessrias para percorrer os elementos da estrutura de dados utilizada.
Podemos encapsular o processo de visitar cada elemento de uma estrutura de dados dentro dela
mesma. Essa abordagem interessante pois cada estrutura conhece a sua organizao interna po-
dendo, dessa forma, implementar esse processo da maneira mais eficiente.
Na plataforma Java, as estruturas que possuem a capacidade de ter os seus elementos percorridos
implementam uma interface que abstrai a ideia desse processo.
Toda estrutura de dados que implementa a interface Iterable deve produzir objetos da interface
Iterator. Os objetos da interface Iterator funcionam como guias que indicam o melhor caminho
para visitar os elementos de uma determinada estrutura.
Organizao
88 www.k19.com.br
89 PADRES C OMPORTAMENTAIS
Aggregate Iterator
<<usa>> <<usa>>
Client next()
createIterator() hasNext()
<<cria>>
ConcreteAggregate1 ConcreteAggregate2 ConcreteIterator1 ConcreteIterator2
<<cria>>
Iterator (Iterator)
Define a interface dos objetos que encapsulam toda a complexidade para percorrer os elemen-
tos do Aggregate.
ConcreteIterator
Implementao da interface Iterator para um tipo especfico de Aggregate.
Aggregate (Iterable)
Define a interface das colees de objetos que podem ter seus elementos percorridos atravs
de um Iterator.
Exerccios de Fixao
8 Defina uma classe ListaDeNomes que implementa a interface Iterable e mantm a lista de
nomes num array.
www.facebook.com/k19treinamentos 89
PADRES C OMPORTAMENTAIS 90
15 private int i = 0;
16
17 public boolean hasNext () {
18 return ( this . i ) < ListaDeNomes . this . length ;
19 }
20
21 public String next () {
22 return ListaDeNomes . this . nomes [ i ++];
23 }
24
25 public void remove () {
26 ListaDeNomes . this . nomes [ i ] = null ;
27
28 for ( int j = i ; ( j + 1) < ListaDeNomes . this . length ; j ++) {
29 ListaDeNomes . this . nomes [ j ] = ListaDeNomes . this . nomes [ j + 1];
30 }
31 ListaDeNomes . this . length - -;
32 }
33 }
34 }
Mediator
Considere a rede de telefonia fixa. Ela permite que ligaes telefnicas sejam realizadas entre
quaisquer dois aparelhos dessa rede. Obviamente, os aparelhos no esto diretamente conectados
entre si dois a dois. Tente imaginar a quantidade de fios que teria de estar conectada a cada aparelho.
90 www.k19.com.br
91 PADRES C OMPORTAMENTAIS
Os telefones esto conectados a uma central que distribui as ligaes de acordo com o nmero
discado, criando uma ligao temporria entre os dois aparelhos.
A ideia do padro Mediator semelhante ideia da central telefnica. Eliminar conexes exces-
sivas entre elementos por meio da introduo de um intermedirio nico.
www.facebook.com/k19treinamentos 91
PADRES C OMPORTAMENTAIS 92
Exemplo prtico
Estamos desenvolvendo um sistema para controlar o fluxo de txis e passageiros em um aero-
porto. Os txis disponveis ficam a espera de passageiros em uma fila organizada pela ordem de
chegada. Da mesma forma, os passageiros que desejam utilizar um txi ficam em uma fila de espera
que tambm organizada pela ordem de chegada.
Criaremos uma classe para modelar os passageiros, outra para os txis e uma terceira para mediar
a comunicao entre esses objetos.
A central de txi deve manter uma fila com os txis disponveis e outra com os passageiros em
espera.
Alm disso, a central de txi deve disponibilizar um mtodo que ser acionado por um txi
quando esse fica disponvel, e outro que ser chamado por um passageiro quando esse entrar na
fila de espera.
Para poder se comunicar com a central de txi, tanto os txis quanto os passageiros devem ter
uma referncia para a central. Essas ligaes podem ser estabelecidas atravs dos construtores das
92 www.k19.com.br
93 PADRES C OMPORTAMENTAIS
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
Client
<<usa>> <<usa>>
<<chama>>
Mediator Colleague
<<chama>>
Mediator
Interface que padroniza as operaes que sero chamadas pelos Colleagues.
ConcreateMediator (CentralDeTaxi)
Implementao particular do Mediator, que coordena a interao entre os Colleagues.
Colleague
Possvel interface para padronizar os ConcreateColleagues.
Exerccios de Fixao
www.facebook.com/k19treinamentos 93
PADRES C OMPORTAMENTAIS 94
13 Adicione classe Taxi um mtodo para simular uma corrida de txi. Adicione tambm um
94 www.k19.com.br
95 PADRES C OMPORTAMENTAIS
www.facebook.com/k19treinamentos 95
PADRES C OMPORTAMENTAIS 96
Observer
Considere um supermercado em que os caixas possuem uma fila nica. Cada caixa identificado
por um nmero, que exibido em uma placa sua frente. Esse nmero fica visvel todos os clientes
da fila.
Tambm visvel aos clientes da fila, existe um painel que exibe o nmero de identificao do
prximo caixa disponvel (se houver algum).
96 www.k19.com.br
97 PADRES C OMPORTAMENTAIS
1 2 3 4
O painel precisa saber sobre as mudanas no estado (livre ou ocupado) de cada caixa para atua-
lizar o seu mostrador.
Uma possibilidade fazer o painel consultar, periodicamente, o estado de cada caixa. Contudo,
essa pode ser uma abordagem ineficiente, principalmente quando o estado dos caixas no alterado
frequentemente.
Uma outra possibilidade fazer com que cada caixa avisasse ao painel sobre uma mudana em
seu estado.
Nessa abordagem, no momento em que um caixa fica disponvel ou ocupado, ele poderia passar
o seu nmero de identificao para o painel, para inform-lo sobre a sua mudana de estado. O
painel, por sua vez, atualizaria o nmero exibido quando necessrio.
A ideia fundamental do padro Observer atribuir aos objetos que tem seus estados alterados a
tarefa de notificar os objetos interessados nessas mudanas. Em nosso exemplo, os caixas notificam
o painel sobre alteraes em seus estados.
Exemplo prtico
Estamos desenvolvendo um sistema para o mercado financeiro. Esse sistema deve manter todos
os interessados em uma determinada ao informados do valor da mesma. Toda alterao no valor
de uma ao deve ser informada aos seus respectivos interessados.
www.facebook.com/k19treinamentos 97
PADRES C OMPORTAMENTAIS 98
Podemos ter vrios tipos de interessados. Por exemplo, uma pessoa fsica, uma empresa, um r-
go pblico, entre outros. Para manter uma padronizao na modelagem, definiremos uma interface
para os interessados.
Por outro lado, a classe Acao deve aceitar interessados (observadores) e avis-los quando o seu
valor for alterado.
Organizao
98 www.k19.com.br
99 PADRES C OMPORTAMENTAIS
<<chama>>
Subject Observer
attach(Observer) <<chama>> update(Subject)
detach(Observer)
getState()
ConcreteObserver1 ConcreteObserver2
ConcreteSubject1 ConcreteSubject1
update(Subject) update(Subject)
attach(Observer) attach(Observer)
detach(Observer) detach(Observer)
getState() getState()
Observer (AcaoObserver)
Interface dos objetos interessados no estado dos Subjects.
ConcreteObserver (Corretora)
Implementao particular de um Observer.
Subject
Interface usada para padronizar os objetos que sero observados.
ConcreteSubject (Acao)
Implementao de um Subject.
Exerccios de Fixao
www.facebook.com/k19treinamentos 99
PADRES C OMPORTAMENTAIS 100
20 }
21 }
19 Para notificar os interessados sobre as alteraes nos valores da ao, devemos registrar os inte-
ressados e notific-los. Para padronizar a notificao dos interessados, criemos a interface AcaoObserver.
20 Altere a classe Acao para registrar os interessados e notific-los sobre a alterao no valor da
ao.
21 Defina a classe Corretora e implemente a interface AcaoObserver para que as corretoras sejam
notificadas sobre as alteraes nos valores das aes.
100 www.k19.com.br
101 PADRES C OMPORTAMENTAIS
State
Objetivo: Alterar o comportamento de um determinado objeto de acordo com o estado no qual ele
se encontra.
Exemplo prtico
Estamos trabalhando em uma empresa que vende taxmetros para o mundo todo. Temos que
implementar a lgica para calcular o valor das corridas de acordo com a bandeira selecionada no
aparelho. O taxmetro pode ser configurado com diversas bandeiras.
www.facebook.com/k19treinamentos 101
PADRES C OMPORTAMENTAIS 102
1 2
R$ 5,00 R$ 10,00
12:30 12:30
Vamos implementar uma interface para padronizar os mtodos das bandeiras do taxmetro.
Depois, necessrio definir as bandeiras do taxmetro de acordo com as necessidades locais, pois
as regras de clculo das corridas so diferentes para cada regio.
102 www.k19.com.br
103 PADRES C OMPORTAMENTAIS
5 }
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
ConcreteStateA ConcreteStateB
handle() handle()
State (Bandeira)
Interface para padronizar os estados do Context.
Context (Taximetro)
Mantm uma referncia para um State que define o estado atual.
Exerccios de Fixao
www.facebook.com/k19treinamentos 103
PADRES C OMPORTAMENTAIS 104
104 www.k19.com.br
105 PADRES C OMPORTAMENTAIS
12
13 double valor2 = taximetro . calculaValorDaCorrida (5 , 30) ;
14 System . out . println ( " Valor da corrida em bandeira 2: " + valor2 ) ;
15 }
16 }
Strategy
Quando desejamos percorrer um trajeto entre dois pontos numa cidade, precisamos decidir qual
caminho devemos seguir. Podem haver diversos caminhos entre dois pontos, o que pode tornar a
escolha de um bom caminho um pouco difcil.
Existem algumas aplicaes que podem ajudar nessa tarefa, como o caso do Google Maps, por
exemplo. Normalmente, essas aplicaes permitem que o usurio escolha a forma ( p, de bicicleta,
de carro, ou usando o transporte pblico) que deseja percorrer o caminho. Essa escolha afeta os
passos para se chegar ao destino final.
www.facebook.com/k19treinamentos 105
PADRES C OMPORTAMENTAIS 106
O padro Strategy prope uma soluo que pode ser adotada nesse cenrio. A ideia fundamental
desse padro possibilitar facilmente a variao do algoritmo a ser utilizado na resoluo de um
problema. Em nosso exemplo, diferentes algoritmos so usados para se encontrar uma rota entre
dois pontos, dependendo do modo como o usurio deseja percorrer o caminho.
Exemplo prtico
Uma tarefa muito comum no desenvolvimento de uma aplicao ordenar uma lista de elemen-
tos. Em Cincia da Computao, foram desenvolvidos diversos algoritmos de ordenao. Podemos
escolher o algoritmo mais apropriado de acordo com a situao.
De qualquer forma, todos os algoritmos de ordenao devem produzir o mesmo resultado, po-
dendo variar no consumo de memria e no tempo gasto para realizar a ordenao.
Podemos definir uma interface para padronizar as diversas implementaes dos algoritmos de
ordenao.
106 www.k19.com.br
107 PADRES C OMPORTAMENTAIS
3 }
Agora, podemos criar uma classe para cada algoritmo que vamos implementar.
Agora podemos escolher qual algoritmo utilizar quando desejamos ordenar uma lista de elemen-
tos.
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
ConcreteStratergyA ConcreteStratergyB
algorithmInterface() algorithmInterface()
Strategy (Sorter)
Interface para padronizar as diferentes estratgias de um algoritmo.
www.facebook.com/k19treinamentos 107
PADRES C OMPORTAMENTAIS 108
Context
Mantm uma referncia para um objeto Strategy e pode permitir que esse acesse os seus
dados.
Exerccios de Fixao
108 www.k19.com.br
109 PADRES C OMPORTAMENTAIS
17 list . remove ( i ) ;
18 list . add (i , aux ) ;
19 }
20 }
21 return list ;
22 }
23 }
Template Method
Objetivo: Definir a ordem na qual determinados passos devem ser realizados na resoluo de um
problema e permitir que esses passos possam ser realizados de formas diferentes de acordo com a situ-
ao.
Em 1913, Henry Ford introduziu o conceito de linha de montagem na produo de carros. Esse
processo permiti at hoje que carros sejam produzidos em grande escala. Em geral, toda linha de
montagem de carros possui trs etapas fundamentais: corte das chapas de ao, pintura do esqueleto
do carro e montagem dos componentes eltricos e mecnicos.
Em geral, essas trs etapas so realizadas na mesma ordem independentemente do tipo de carro
que est sendo produzido. Contudo, obviamente, para cada tipo de carro, essas etapas so realizadas
de maneiras diferentes.
www.facebook.com/k19treinamentos 109
PADRES C OMPORTAMENTAIS 110
Exemplo prtico
Estamos desenvolvendo um sistema bancrio e precisamos modelar os diversos tipos de contas
do banco. Decidimos aplicar herana utilizando uma classe chamada Conta.
Toda operao bancria realizada gera a cobrana de uma taxa que diferente para cada tipo da
conta. Podemos tentar implementar um mtodo para calcular essa taxa na classe Conta e cham-lo
a partir dos outros mtodos.
110 www.k19.com.br
111 PADRES C OMPORTAMENTAIS
Contudo, nada pode ser definido no corpo do mtodo calculaTaxa() na classe Conta porque o
clculo diferente para cada tipo de conta bancria. A soluo tornar o mtodo abstrato para que
ele seja implementado nas classes das contas especficas. Dessa forma, os mtodos que chamam o
calculaTaxa() dependem de um mtodo que ser implementado posteriormente.
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
AbstractClass
template()
primitiveOperation1()
primitiveOperation2()
ConcreteClass1 ConcreteClass2
primitiveOperation1() primitiveOperation1()
primitiveOperation2() primitiveOperation2()
www.facebook.com/k19treinamentos 111
PADRES C OMPORTAMENTAIS 112
AbstractClass (Conta)
Classe abstrata que define os templates methods baseados em mtodos abstratos que sero
implementados nas ConcreteClasses.
Exerccios de Fixao
33 Defina a classe Conta e o mtodo abstrato calculaTaxa. A cada operao uma taxa cobrada.
112 www.k19.com.br
113 PADRES C OMPORTAMENTAIS
Visitor
Objetivo: Permitir atualizaes especficas em uma coleo de objetos de acordo com o tipo parti-
cular de cada objeto atualizado.
Exemplo prtico
Estamos desenvolvendo um sistema bancrio no qual os funcionrios devem ser classificados de
acordo com o cargo que eles possuem. Para modelar as diferenas e semelhanas relativas a cada
cargo decidimos aplicar o conceito de herana na nossa modelagem.
www.facebook.com/k19treinamentos 113
PADRES C OMPORTAMENTAIS 114
Todo funcionrio do banco est associado a um departamento. Podemos aplicar agregao para
implementar essa condio.
Podemos implementar o reajuste ou qualquer outra tarefa de atualizao dos dados dos funcio-
nrios atravs de classes especializadas. Inclusive, podemos definir uma interface para padronizar a
interao com essas classes.
Agora, suponha que no sistema h uma lista com todos os departamentos do banco. Queremos
aplicar um atualizador em todos os funcionrios de todos os departamentos dessa lista.
Contudo temos dois problemas: primeiro, possvel que o acesso aos funcionrios de um depar-
tamento esteja restrito, consequentemente, dentro do lao acima no poderamos executar o atuali-
zador. Segundo, mesmo que o acesso esteja disponvel, teramos que testar o tipo dos funcionrios
de cada departamento para selecionar o mtodo correto de atualizao.
114 www.k19.com.br
115 PADRES C OMPORTAMENTAIS
Para solucionar os dois problemas acima, podemos passar os atualizadores para dentro dos de-
partamentos e dos funcionrios para que eles prprios chamem o mtodo correto de atualizao. Os
atualizadores podem ser passados para dentro dos departamentos e dos funcionrios atravs de um
mtodo padronizado por uma interface.
www.facebook.com/k19treinamentos 115
PADRES C OMPORTAMENTAIS 116
Organizao
O diagrama UML abaixo ilustra a organizao desse padro.
Client Visitor
visitElementA()
visitElementB()
ConcreteVisitor1 ConcreteVisitor2
visitElementA() visitElementA()
visitElementB() visitElementB()
Element
ObjectStructure
accept(Visitor)
ConcreteElement1 ConcreteElement2
accept(Visitor) accept(Visitor)
Visitor (AtualizadorDeFuncionario)
Define a interface dos objetos responsveis pelas atualizaes dos Elements.
ConcreteVisitor (AtualizadorSalarial)
Implementa a lgica de uma determinada atualizao dos Elements.
116 www.k19.com.br
117 PADRES C OMPORTAMENTAIS
Element (Atualizavel)
Define a interface dos objetos que podem ser atualizados por um Visitor.
ObjectStructure
Agregador dos Elements.
Client
Aplica um determinado Visitor nos Elements do ObjectStructure.
Exerccios de Fixao
www.facebook.com/k19treinamentos 117
PADRES C OMPORTAMENTAIS 118
118 www.k19.com.br
119 PADRES C OMPORTAMENTAIS
www.facebook.com/k19treinamentos 119
PADRES C OMPORTAMENTAIS 120
120 www.k19.com.br