Aula 04 - UML e Padrões de Projeto

!
!
Especialização!em!Desenvolvimento!Java!!
UML$e$Padrões$de$Projetos$!
AULA!04!–!INTRODUÇÃO!AOS!PADRÕES!DE!PROJETO!
Prof.!Vinícius!de!Paula!K!viniciusdepaula@unitri.edu.br!

Evolução$do$So8ware$
“Grandes( sistemas( de( so-ware( nunca( são( concluídos,( eles( simplesmente(
con6nuam(evoluindo”![Lehman]!
UML e Padrões de Projeto Centro Universitário do Triângulo 3

•  MoRvos!e!consequências!(algumas!Leis!de!Lehman)!
•  Mudança!ConYnua!e!Crescimento!ConYnuo!
- Mudanças!são!inevitáveis!para!que!o!so[ware!conRnue!úRl!
- Adição!de!funcionalidades!para!manter!a!saRsfação!do!usuário!

•  MoRvos!e!consequências!(algumas!Leis!de!Lehman)!
•  Mudança!ConYnua!e!Crescimento!ConYnuo!
- Mudanças!são!inevitáveis!para!que!o!so[ware!conRnue!úRl!
- Adição!de!funcionalidades!para!manter!a!saRsfação!do!usuário!
•  Complexidade!Crescente!e!Qualidade!Decrescente!
- Mudanças!aumentam!a!complexidade!do!so[ware!
- Qualidade!diminui!a!não!ser!que!haja!adaptações!

Como$devemos$proceder?$
Pensar antes de agir!
Algumas$ações:$
•  Analisar!impactos!
•  Modelar,!antes!de!codiﬁcar!
•  URlizar!soluções!e!técnicas!validadas!
- Não!reinventar!a!roda!!

A$Inspiração$
•  A! ideia! de! padrões! foi! apresentada! por!
Christopher!Alexander!em!1977!no!contexto!de!
Arquitetura!(de!prédios!e!cidades):!
Cada$ padrão$ descreve$ um$ problema$ que$ ocorre$
repe0damente$ em$ nosso$ ambiente,$ e$ então$
descreve$ a$ parte$ central$ da$ solução$ para$ aquele$
problema$de$uma$forma$que$você$pode$usar$esta$
solução$ um$ milhão$ de$ vezes,$ sem$ nunca$
implementa<la$duas$vezes$da$mesma$forma.$

Padrões$de$Projeto$ou$Design$PaFerns$
Para! não! perder! tempo! e! dinheiro! elaborando! soluções! diferentes! para! o!
mesmo!problema,!poderíamos!escolher!uma!solução!como!padrão!e!adotáKla!
toda!vez!que!o!problema!correspondente!ocorrer.!!
!

Além! de! evitar! o! retrabalho,! facilitaríamos! a! comunicação! dos!
desenvolvedores!e!o!entendimento!técnico!do!sistema.!!

Além! de! evitar! o! retrabalho,! facilitaríamos! a! comunicação! dos!
desenvolvedores!e!o!entendimento!técnico!do!sistema.!!
Neste!contexto,!surge!o!conceito!de!padrões$de$projeto!ou!design$paFerns:!
Um$ padrão$ de$ projeto$ é$ uma$ solução$ consolidada$ para$ um$ problema$
recorrente$ no$ desenvolvimento$ e$ manutenção$ de$ soAware$ orientado$ a$
objetos.$

Por$que$aprender$padrões?$
•  Aprender!com!a!experiência!dos!outros!
•  IdenRﬁcar!problemas!comuns!em!engenharia!de!so[ware!
•  URlizar!soluções!testadas!e!bem!documentadas!

•  Aprender!boas!práRcas!de!programação!
•  Padrões! uRlizam! eficientemente! herança,! composição,! modularidade,!
polimorfirmo!e!abstração!para!construir!código!reuRlizável,!eficiente,!de!
alta!coesão!e!baixo!acoplamento!

•  Aprender!boas!práRcas!de!programação!
•  Padrões! uRlizam! eficientemente! herança,! composição,! modularidade,!
polimorfirmo!e!abstração!para!construir!código!reuRlizável,!eficiente,!de!
alta!coesão!e!baixo!acoplamento!
•  Ter!um!caminho!e!um!alvo!para!refatorações!
•  Facilitar!a!comunicação,!compreensão!e!documentação!
•  Vocabulário!comum!
•  Ajuda!a!entender!o!papel!das!classes!do!sistema!

O$Formato$de$um$Padrão$
•  Nome!
•  Problema!
•  Quando!aplicar!o!padrão,!em!que!condições?!
•  Solução!
•  Descrição! abstrata! de! um! problema! e! como! usar! os! elementos!
disponíveis!(classes!e!objetos)!para!solucionáKlo.!
•  Consequências!
•  Custos!e!benemcios!de!se!aplicar!o!padrão.!
•  Impacto! na! ﬂexibilidade,! extensibilidade,! portabilidade! e! eﬁciência! do!
sistema.!

Padrões$de$Projeto$GoF$
•  Descreve!23!padrões!de!projeto!“clássicos”!
•  Soluções! genéricas! para! os! problemas! mais!
comuns! do! desenvolvimento! de! so[ware!
orientado!a!objetos!
•  ObRdas!através!de!experiências!de!sucesso!na!
indústria!de!so[ware!
•  Sobre!o!livro!
•  Seus!quatro!autores!são!conhecidos!como!"The!
Gang!of!Four !(GoF).!
•  O! livro! tornouKse! um! clássico! na! literatura!
orientada!a!objetos!e!conRnua!atual.!

Mais$Padrões?$
•  Há!vários!catálogos!de!padrões!para!so[ware!
•  Muitos!são!especíﬁcos!a!uma!determinada!área!
•  Padrões!Java!EE!!
•  Padrões!de!implementação!Java!ou!C#!!
!

Classiﬁcação$dos$Padrões$

Formas$de$Classificação$dos$Padrões$
Há!várias!formas!de!classificar!os!padrões!
•  Os!padrões!GoF!são!tradicionalmente!classificados!pelo!propósito:!
•  Criação!de!classes!e!objetos!
•  Alteração!da!estrutura!de!um!programa!
•  Controle!do!seu!comportamento$
•  Metsker$os!classifica!em!5!grupos,!por!intenção:!
•  Oferecer!uma!interface$
•  Atribuir!uma!responsabilidade!!
•  Realizar!a!construção!de!classes!ou!objetos!
•  Controlar!formas!de!operação$
•  Implementar!uma!extensão!para!a!aplicação!
!

Padrões$GoF$P$Classiﬁcação$por$Propósito$$
Propósito$
Criação$ Estrutura$ Comportamento$
Escopo$
Classe$
Factory!Method! Class!Adapter! Interpreter!
Template!Method!
Objeto$
Builder!
Abstract!Factory!
Prototype!
Singlenton!
Object!Adapter!
Bridge!
Composite!
Decorator!
Facade!
Flyweight!
Proxy!
Chain!of!Responsibility!
Command!
Iterator!
Mediator!
Memento!
Observer!
State!
Strategy!
Visitor!
Classiﬁcação(segundo(GoF(

Padrões$GoF$P$Classiﬁcação$por$Intenção$
Intenção$ Padrões$
Interfaces$ Adapter,!Facade,!Composite,!Bridge!
Construção$ Factory!Method,!Abstract!Factory,!!
Builder,!Prototype,!Memento!
Responsabilidade$
$
Singleton,!Observer,!Chain!of!Responsibility,!
Mediator,!Proxy,!Flyweight!
Operações$ Template!Method,!State,!Command,!Strategy,!
Interpreter!
Extensões! Iterator,Decorator,!Visitor!
Classiﬁcação(segundo(Steven(Metsker(

BemPVindo$aos$Padrões$de$Projeto$

O$Cenário$
Manoel! trabalha! em! uma! empresa! que! criou! um! jogo! de!
simulação! de! um! lago! com! patos.! O! jogo! pode! mostrar! uma!
grande! variedade! de! espécies! de! patos! nadando! e! produzindo$
sons.!Os!arquitetos!do!sistema!usaram!técnicas!OO!e!chegaram!ao!
seguinte!modelo!de!classes.!
!

O$Cenário$
!
Duck( MallardDuck( RedheadDuck(

O$Cenário$
!

O$Cenário$
!
Todos!os!patos!
grasnam!e!nadam$

O$Cenário$
!
Todos!os!patos!
grasnam!e!nadam$
O!método!display()!é!
abstrato!já!que!todos!
os!subRpos!de!patos!
são!diferentes!!$

O$Cenário$
!
Todos!os!patos!
grasnam!e!nadam$
são!diferentes!!$
Um método abstrato obriga a classe em que ele se encontra
ser abstrata. Dessa forma, podemos assumir que a classe
Duck é abstrata.

O$Cenário$
!
Todos!os!patos!
grasnam!e!nadam$
são!diferentes!!$
Cada!subRpo!de!pato!
implementa!seu!próprio!
comportamento!de!
como!ele!será!exibido!
na!tela!!

O$Cenário$
!
Todos!os!patos!
grasnam!e!nadam$
são!diferentes!!$
Cada!subRpo!de!pato!
implementa!seu!próprio!
comportamento!de!
como!ele!será!exibido!
na!tela!
Muitos!outros!Rpos!
de!patos!são!
subclasses!de!Duck(

Surge$uma$manutenção$no$sistema...$
Os! execuRvos! da! empresa! decidiram! que! fazer! os!
patos!voarem!é!o!que!o!simulador!precisa!para!acabar!
com!a!concorrência.!

O que precisamos fazer para os patos voarem?

Todas!as!subclasses!
agora!herdam!o!
comportamento!de!voar$

Após! a! atualização! do! sistema,! em! plena!
demonstração!do!simulador!para!os!acionistas,!patos$
de$borracha!começaram!a!voar!pela!tela.!

Ao!incluirmos!o!método!fly()!
na!superclasse,!demos!a!
capacidade!de!voar!a!todos!os!
Rpos!de!patos,!incluindo!os!
que!não!deveriam!voar!$

Patos!de!borracha!
não$grasnam,!quack()!
foi!sobrescrito!para!
implementar!o!som!
de!“Squeak”$
Ao!incluirmos!o!método!fly()!
na!superclasse,!demos!a!
capacidade!de!voar!a!todos!os!
Rpos!de!patos,!incluindo!os!
que!não!deveriam!voar!$

Após a manutenção, objetos inanimados estavam voando no simulador.
A utilização de herança para fins de reutilização não é bem recebida
quando temos uma manutenção pela frente.

Pensando$sobre$herança...$
Poderíamos! sobrescrever! o! método! ﬂy()! na! classe!
RubberQuack,! similar! ao! que! ﬁzemos! com! o! método!
quack().!

Poderíamos! sobrescrever! o! método! fly()! na! classe!
RubberQuack,! similar! ao! que! fizemos! com! o! método!
quack().!
O!método!fly()!foi!
sobrescrito,!mas!não!
possui!nenhum!
comportamento!para!
implementar!
!$

E!se!surgissem!novo!Rpos!de!patos!a!serem!tratados!pelo!
simulador?! Como! um! pato$ de$ madeira.! Ele! não! deve!
voar!nem!grasnar...!

Os!métodos!quack()!e!ﬂy()!
foram!sobrescritos!mas!não!
possuem!comportamentos!
!$

Com!o!que!vimos!até!agora,!quais!opções!a!seguir!podem!
ser!consideradas!desvantagens!ao!se!uRlizar!herança!para!
produzir!o!comportamento!de!Duck?!

a)  O!código!é!duplicado!entre!subclasses.!
b)  Não!podemos!fazer!patos!dançar.!
c)  É!dimcil!conhecer!o!comportamento!de!todos!os!patos.!
d)  Os!patos!não!conseguem!voar!e!grasnar!ao!mesmo!tempo.!
e)  As!alterações!podem!afetar!sem!querer!outros!patos.!
!

Pontos$a$repensar...$
•  E!se!o!produto!precisasse!ser!atualizado!a!cada!3!meses!ou!menos,!devido!a!
uma!decisão!estratégica!de!negócio?!
•  A! cada! atualização! as! especiﬁcações! do! produto! conRnuarão! mudando! e!
seremos!forçados!a!sobrescrever!os!métodos!ﬂy()!e!quack()!para!cada!nova!
subclasse!de!Duck.!

subclasse!de!Duck.!
Quando utilizamos herança a manutenção do código se torna
mais complexa e propícia a erros

subclasse!de!Duck.!
Precisamos de uma maneira mais simples para que apenas
alguns (mas não todos) tipos de patos voem ou grasnem.

Que$tal$uma$Interface?$
•  Poderíamos!Rrar!o!método!fly()!da!superclasse!Duck!e!criar!
uma!interface!Flyable!com!um!método!fly().!
•  Dessa! forma,! somente! os! patos! que! devem! voar! irão!
implementar!esta!interface!e!ter!um!método!fly().!
•  Além!disso,!poderíamos!criar!o!método!Quackable!pois!nem!
todos!os!patos!podem!grasnar.!

•  Poderíamos!Rrar!o!método!fly()!da!superclasse!Duck!e!criar!
uma!interface!Flyable!com!um!método!fly().!
•  Dessa! forma,! somente! os! patos! que! devem! voar! irão!
implementar!esta!interface!e!ter!um!método!fly().!
•  Além!disso,!poderíamos!criar!o!método!Quackable!pois!nem!
todos!os!patos!podem!grasnar.!
Uma Interface é um contrato onde quem assina se
responsabiliza por implementar seus métodos. Ela expõe o
que o objeto deve fazer e não como ele faz.

Interpretação da Interface
Quem desejar ser “Flyable” precisa saber voar.
Quem desejar ser “Quackable” precisa saber grasnar.

Interpretação de quem implementa a Interface
A classe RubberDuck se compromete a ser tratada como
Quackable, sendo obrigada a ter os métodos necessários,
definidos neste contrato.

E se precisarmos fazer uma pequena alteração no
comportamento de vôo... de todas as inúmeras subclasses de
Duck que voam?

Repensando$a$Interface...$
•  Vimos!que!nem!todas!as!subclasses!devem!ter!o!comportamento!de!voar!ou!
grasnar,!então!o!uso!de!herança!não!foi!uma!solução!adequada.!
•  Implementar! Flyable! e! Quackable! nas! subclasses! resolveu! parte! do!
problema!(sem!fazer!patos!de!borracha!voarem!inadequadamente),!porém!
degradou! completamente! a! reu_lização! de! código! para! esses!
comportamentos,!criando!apenas!um!pesadelo!de!manutenção!diferente.!

Repensando$a$Interface...$
•  Vimos!que!nem!todas!as!subclasses!devem!ter!o!comportamento!de!voar!ou!
grasnar,!então!o!uso!de!herança!não!foi!uma!solução!adequada.!
•  Implementar! Flyable! e! Quackable! nas! subclasses! resolveu! parte! do!
problema!(sem!fazer!patos!de!borracha!voarem!inadequadamente),!porém!
degradou! completamente! a! reu_lização! de! código! para! esses!
comportamentos,!criando!apenas!um!pesadelo!de!manutenção!diferente.!
É notório que pode haver mais de um tipo de comportamento
de vôo até entre os patos que voam.

A$Constante$no$Desenvolvimento$de$So8ware$
•  Qual!a!única!coisa!com!a!qual!podemos!contar!sempre!no!
desenvolvimento!de!so[ware?!
!

•  Não!importa!onde!você!trabalha,!o!que!está!criando!ou!em!
que! linguagem! está! programando,! qual! a! constante! que!
estará!sempre!com!você?!

ALTERAÇÃO

Independentemente de como você desenvolva uma aplicação,
com o tempo ela precisará crescer e mudar para não morrer.

Independentemente de como você desenvolva uma aplicação,
com o tempo ela precisará crescer e mudar para não morrer.
“Sistemas devem ser continuamente adaptados ou eles
se tornam progressivamente menos satisfatórios.”
[Lehman]

Muitas!coisas!podem!causar!mudanças.!Relacione!alguns!
moRvos! pelos! quais! você! precisou! alterar! o! código! de!
alguma!aplicação?!

Repensando$o$Problema$
•  Herança!não!funcionou!muito!bem:!
•  O!comportamento!do!pato!conRnua!mudando!entre!as!subclasses;!
•  Não! é! apropriado! que! todas! as! subclasses! tenham! estes!
comportamentos.!
•  Foi!promissor!usarmos!os!conceitos!de!Interface,!mas:!
•  Não!Rvemos!reaproveitamento!de!código;!
•  Sempre!que!um!comportamento!for!modiﬁcado!todas!as!subclasses!que!
o!implementam!devem!ser!alteradas.!

#1$Princípios$de$Projeto$
Iden_ﬁque$ os$ aspectos$ de$ sua$ aplicação$ que$ variam$ e$ separePos$ do$ que$
permanece$igual.!

permanece$igual.$
•  Em!outras!palavras:!Pegue!as!partes!que!variam!e!encapsuleKas!para!depois!
poder!alterar!ou!estender!estas!partes!sem!afetar!as!que!não!variam.!

permanece$igual.$
•  Em!outras!palavras:!Pegue!as!partes!que!variam!e!encapsuleKas!para!depois!
poder!alterar!ou!estender!estas!partes!sem!afetar!as!que!não!variam.!
Isso traz menos consequências indesejadas nas alterações
realizadas no código e maior flexibilidade.

Separando$as$partes$que$variam$das$que$ﬁcam$iguais$
•  Vamos!criar!dois!conjuntos!de!classes,!um!para!!voar!e!e!outro!para!grasnar.!
•  Cada! conjunto! de! classes! irá! conter! todas! as! implementações! de! seu!
comportamento.!
!

comportamento.!
!
Sabemos que fly() e quack() são as partes da classe Duck
que variam entre os patos.

comportamento.!
!
!
Classe
Duck
Comportamentos
de Grasnar
Comportamentos
de Voar
Comportamentos de Duck

comportamento.!
!
!
Classe
Duck
Comportamentos
de Grasnar
Comportamentos
de Voar
Separe o que varia

comportamento.!
!
!
Classe
Duck
Comportamentos
de Grasnar
Comportamentos
de Voar
Separe o que varia
Do que fica igual

Pensando$na$Solução...$
Como$ vamos$ desenvolver$ o$ conjunto$ de$ classes$ que$
implementam$os$comportamentos$de$voar$e$grasnar?$
!
!

Pensando$na$Solução...$
Como$ vamos$ desenvolver$ o$ conjunto$ de$ classes$ que$
implementam$os$comportamentos$de$voar$e$grasnar?$
•  Gostaríamos!de!manter!a!arquitetura!ﬂexível.!
•  Queremos!atribuir!comportamentos!às!instâncias!da!
classe!Duck;!
•  Poderíamos! alterar! o! comportamento! de! uma!
instância!de!Duck!em!tempo!de!execução.!

Programa$para$uma$Interface$e$não$para$uma$implementação.$

Cada!comportamento!
será!!representado!por!
uma!Interface$

Cada!comportamento!
uma!Interface$
Implementa!o!vôo!do!
pato$

Cada!comportamento!
uma!Interface$
pato$
Não!possui!
implementação,!pois!é!
um!comportamento!para!
quem!não!sabe!voar$

Cada!comportamento!
uma!Interface$
pato$
Não!possui!
implementação,!pois!é!
um!comportamento!para!
quem!não!sabe!voar$
Dessa forma, as classes derivadas de Duck não precisam conhecer
nenhum detalhe de implementação dos seus comportamentos

Com o novo design, as classes derivadas de Duck irão
usar um comportamento representado por uma
Interface.
A implementação real do comportamento não fica
acoplada às classes derivadas de Duck.

Implementando$os$Comportamentos$

Somente!as!classes!de!
vôo!implementam!
esta!Interface$

vôo!implementam!
esta!Interface$
Implementação!de!
voar!para!todos!os!
patos!que!têm!asas$

vôo!implementam!
esta!Interface$
Implementação!de!
voar!para!todos!os!
Implementação!dos!
patos!que!não!
sabem!voar$

vôo!implementam!
esta!Interface$
Implementação!de!
voar!para!todos!os!
patos!que!não!
sabem!voar$
Implementação!de!
grasnar!para!os!Rpos!
de!patos!que!
grasnam$

vôo!implementam!
esta!Interface$
Implementação!de!
voar!para!todos!os!
patos!que!não!
sabem!voar$
Implementação!para!
os!Rpos!de!patos!que!
não!emitem!som!$
Implementação!de!
grasnar!para!os!Rpos!
de!patos!que!
grasnam$

Outros tipos de objetos podem reutilizar nossos
comportamentos de voar e grasnar.
Além disso, podemos adicionar novos comportamentos
sem modificar nenhuma de nossas classes de
comportamentos existentes.

Pensando$em$reuso...$
Usando! o! nosso! novo! projeto,! o! que! você! faria! se!
precisasse!adicionar!um!vôo!de!foguete!à!aplicação?!
!
Você! consegue! pensar! numa! classe! que! poderia! usar! o!
comportamento!de!Quack!que!não!seja!um!pato?!
!
!
!

Pensando$em$reuso...$
Usando! o! nosso! novo! projeto,! o! que! você! faria! se!
precisasse!adicionar!um!vôo!de!foguete!à!aplicação?!
Poderíamos$ criar$ uma$ classe$ FlyRocket$ que$
implementasse$a$interface$FlyBehaviour.!
Você! consegue! pensar! numa! classe! que! poderia! usar! o!
comportamento!de!Quack!que!não!seja!um!pato?!
Uma$classe$que$representasse$um$disposi_vo$eletrônico$
que$simula$sons$de$pato.!
!
!
!

Integrando$o$Comportamento$
Delegaremos$ o$ comportamento$ de$ voar$ e$ grasnar$ em$ vez$ de$ usar$ os$
métodos$deﬁnidos$nas$subclasses$de$Duck.$
!

•  Vamos! adicionar! duas! variáveis! de! instância! à! classe! Duck$ chamadas!
ﬂyBehaviour!e!quackBehaviour.!

•  Iremos! remover! os! métodos! ﬂy()! e! quack()! da! classe! Duck! e! de! suas!
subclasses!pelo!fato!de!estarmos!delegando!estes!comportamentos!para!as!
classes!FlyBehaviour!e!QuackBehaviour.!
!
!

•  Iremos! remover! os! métodos! ﬂy()! e! quack()! da! classe! Duck! e! de! suas!
subclasses!pelo!fato!de!estarmos!delegando!estes!comportamentos!para!as!
classes!FlyBehaviour!e!QuackBehaviour.!
•  Incluiremos! dois! novos! métodos! à! classe! Duck,! chamados! performFly! e!
performQuack.$
!
!

Modelo$x$Implementação$
public abstract class Duck {
FlyBehavior flyBehavior;
QuackBehavior quackBehavior;
public Duck() {
}
public void performFly() {
flyBehavior.fly();
}
public void performQuack() {
quackBehavior.quack();
}
// outros métodos aqui..
}

Modelo$x$Implementação$

Mais$integração...$
•  Como! agora! estamos! delegando! o! comportamento! de! voar! e! grasnar,!
temos!que!deﬁnir!as!variáveis!de!instância!ﬂyBehaviour!e!quackBehaviour!
nas!subclasses!de!Duck.!!

public class MallardDuck extends Duck {
public MallardDuck() {
quackBehavior = new Quack();
flyBehavior = new FlyWithWings();
}
public void display() {
System.out.println("I'm a real Mallard duck");
}
}

}
}
}
A!classe!MallarDuck!
herda!a!variáveis!de!
instância!de!Quack$$

}
}
}
A!responsabilidade!de!
grasnar!é!delegada!ao!
objeto!Quack$$

}
}
}
Como!MallarDuck!
sabe!como!voar!este!
comportamento!é!
uRlizado$

Comportamento$Dinâmico$
Como$podemos$alterar$o$comportamento$de$um$Duck$
após$sua$instanciação?$

Como$podemos$alterar$este$comportamento$de$forma$
dinâmica$(em$tempo$de$execução)?$

Como$podemos$alterar$este$comportamento$de$forma$
dinâmica$(em$tempo$de$execução)?$
Por meio da mágica do polimorfismo, podemos atribuir dinamicamente
uma classe de implementação diferente em tempo de execução.

•  Vamos!adicionar!dois!novos!métodos!à!classe!Duck.!
!
!
!
public void setFlyBehavior (FlyBehavior fb) {
flyBehavior = fb;
}
public void setQuackBehavior(QuackBehavior qb) {
quackBehavior = qb;
}

•  Criaremos!um!novo!Rpo!de!pato.!
!
!
!
public class ModelDuck extends Duck {
public ModelDuck() {
flyBehavior = new FlyNoWay();
}
System.out.println("I'm a model duck");
}
}

•  Criaremos!um!novo!Rpo!de!pato.!
!
!
!
public class ModelDuck extends Duck {
public ModelDuck() {
flyBehavior = new FlyNoWay();
}
System.out.println("I'm a model duck");
}
}
O!novo!modelo!de!
pato!começa!a!vida!no!
chão,!sem!nenhuma!
maneira!de!voar!

•  Vamos!criar!um!novo!Rpo!de!FlyBehaviour.!
!
!
!
public class FlyRocketPowered implements FlyBehavior {
public void fly() {
System.out.println("I'm flying with a rocket");
}
}

•  Altere!a!sua!classe!de!teste,!instanciando!um!novo!ModelDuck!e!alterando!o!
seu!comportamento!para!voar!como!um!foguete.!
!
!
!
public class DuckSimulator {
public static void main(String[] args) {
Duck mallard = new MallardDuck();
mallard.performQuack();
mallard.performFly();
Duck model = new ModelDuck();
model.performFly();
model.setFlyBehavior(new FlyRocket());
model.performFly();
}
}

!
!
!
model.performFly();
model.performFly();
}
}
A!primeira!chamada!ao!método!
performFly()!delega!o!
comportamento!para!o!
ﬂyBehaviour$deﬁnido!no!
construtor!de!ModelDuck!

!
!
!
model.performFly();
model.performFly();
}
}
Para!alterar!o!comportamento!de!
um!Duck!em!tempo!de!execução,!
basta!chamar!um!dos!métodos!
polifórmicos!que!criamos!

!
!
!
model.performFly();
model.performFly();
}
}
Quando!o!performFly!é!
chamado,!o!pato!voará!como!
um!foguete!

Modelo$de$Classes$

Dar$prioridade$à$composição$
•  Cada!pato!tem!um!FlyBehaviour!e!um!QuackBehaviour!aos!quais!delega!as!
capacidades!de!voar!e!grasnar.!

Dar$prioridade$à$composição$
•  Cada!pato!tem!um!FlyBehaviour!e!um!QuackBehaviour!aos!quais!delega!as!
capacidades!de!voar!e!grasnar.!
Criar sistemas usando composições nos permite:
-  Uma maior flexibilidade;
-  Encapsular uma família de algoritmos em seu próprio conjunto de
classes;
- Alterar o comportamento de objetos em tempo de execução.

Padrão$Strategy$
•  Acabamos! de! aplicar! o! nosso! primeiro! padrão! de! projetos,! o! padrão!
Strategy.!
•  O!padrão!Strategy!deﬁne!uma!família!de!objetos,!encapsula!cada!um!deles!
e! o! torna! ! intercambiáveis.! O! Strategy! deixa! o! algoritmo! variar!
independentemente!dos!clientes!que!o!uRlizam.!

Bibliograﬁa$
•  Ian! Sommerville.! Engenharia! de! So[ware,! 9a! Edição.! Pearson! EducaRon,!
2011.!
•  Erich! Freeman,! Elizabeth! Freeman.! HeadFirst! –! Design! PaÄerns.! O! ́REILLY!
2004.!
•  METSKER,!J.!Design!PaÄerns!Java!Workbook.!EUA:!AddisonKWesley!2002.!

Aula 04 - UML e Padrões de Projeto

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (16)

Último

Último (20)

Aula 04 - UML e Padrões de Projeto