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í[email protected]!

Introdução$a$Padrões$

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!codificar!•  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!

•  IdenRficar!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! flexibilidade,! extensibilidade,! portabilidade! e! eficiê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íficos!a!uma!determinada!área!•  Padrões!Java!EE!!•  Padrões!de!implementação!Java!ou!C#!!

!


Classificaçã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!

!UML e Padrões de Projeto Centro Universitário do Triângulo 18

Padrões$GoF$P$Classificaçã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!

** Classificação segundo GoF. ** Classificação segundo GoF.

Classificação(segundo(GoF(

Padrões$GoF$P$Classificaçã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!

Classificaçã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.!

!



!


Duck( MallardDuck( RedheadDuck(


!



!


Todos!os!patos!grasnam!e!nadam$


!


Todos!os!patos!grasnam!e!nadam$O!método!display()!é!

abstrato!já!que!todos!os!subRpos!de!patos!

são!diferentes!!$


!




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.


!




são!diferentes!!$

Cada!subRpo!de!pato!implementa!seu!próprio!comportamento!de!

como!ele!será!exibido!na!tela!!


!




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$

Surge$uma$manutenção$no$sistema...$Após! a! atual ização! do! s istema,! 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! fly()! na! classe!RubberQuack,! similar! ao! que! fizemos! com! o! método!quack().!


Pensando$sobre$herança...$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!!$

Pensando$sobre$herança...$


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!fly()!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! especificações! do! produto! conRnuarão! mudando! e!seremos!forçados!a!sobrescrever!os!métodos!fly()!e!quack()!para!cada!nova!subclasse!de!Duck.!





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




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.!


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.!


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.

Que$tal$uma$Interface?$




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!modificado!todas!as!subclasses!que!o!implementam!devem!ser!alteradas.!


Princípios$de$Projeto$

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


#1$Princípios$de$Projeto$Iden_fique$ os$ aspectos$ de$ sua$ aplicação$ que$ variam$ e$ separePos$ do$ que$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.!


#1$Princípios$de$Projeto$Iden_fique$ os$ aspectos$ de$ sua$ aplicação$ que$ variam$ e$ separePos$ do$ que$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.

#1$Princípios$de$Projeto$Separando$as$partes$que$variam$das$que$ficam$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.!

!





!


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




!

!


Classe Duck

Comportamentos de Grasnar

Comportamentos de Voar

Comportamentos de Duck




!

!


Classe Duck




Separe o que varia




!

!


Classe Duck




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!flexí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.!

!


#2$Princípios$de$Projeto$Programa$para$uma$Interface$e$não$para$uma$implementação.$




Cada!comportamento!será!!representado!por!

uma!Interface$




uma!Interface$

Implementa!o!vôo!do!pato$




uma!Interface$


Não!possui!implementação,!pois!é!

um!comportamento!para!quem!não!sabe!voar$




uma!Interface$


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

#2$Princípios$de$Projeto$


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$




Implementação!de!voar!para!todos!os!patos!que!têm!asas$





Implementação!dos!patos!que!não!sabem!voar$






Implementação!de!grasnar!para!os!Rpos!

de!patos!que!grasnam$






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$ cr iar$ uma$ c lasse$ F lyRocket$ 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$definidos$nas$subclasses$de$Duck.$

!



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




•  Iremos! remover! os! métodos! fly()! 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! fly()! 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.$

!

!UML e Padrões de Projeto Centro Universitário do Triângulo 94

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!definir! as! variáveis! de! instância!flyBehaviour! 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.

Comportamento$Dinâmico$•  Vamos!adicionar!dois!novos!métodos!à!classe!Duck.!

!

!

!


public void setFlyBehavior (FlyBehavior fb) {

flyBehavior = fb;} public void setQuackBehavior(QuackBehavior qb) {

quackBehavior = qb;}

Comportamento$Dinâmico$•  Criaremos!um!novo!Rpo!de!pato.!

!

!

!


public class ModelDuck extends Duck {

public ModelDuck() {

flyBehavior = new FlyNoWay();quackBehavior = new Quack();

}

public void display() {System.out.println("I'm a model duck");

}}

Comportamento$Dinâmico$•  Criaremos!um!novo!Rpo!de!pato.!

!

!

!


public class ModelDuck extends Duck {

public ModelDuck() {

flyBehavior = new FlyNoWay();quackBehavior = new Quack();

}

public void display() {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!

Comportamento$Dinâmico$•  Vamos!criar!um!novo!Rpo!de!FlyBehaviour.!

!

!

!


public class FlyRocketPowered implements FlyBehavior {

public void fly() {

System.out.println("I'm flying with a rocket");

}}

Comportamento$Dinâmico$•  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();

}}


!

!

!






}}

A!primeira!chamada!ao!método!performFly()!delega!o!comportamento!para!o!flyBehaviour$definido!no!construtor!de!ModelDuck!


!

!

!






}}

Para!alterar!o!comportamento!de!um!Duck!em!tempo!de!execução,!basta!chamar!um!dos!métodos!

polifórmicos!que!criamos!


!

!

!






}}

Quando!o!performFly!é!chamado,!o!pato!voará!como!

um!foguete!

Modelo$de$Classes$


#3$Princípios$de$Projeto$Dar$prioridade$à$composição$

•  Cada!pato!tem!um!FlyBehaviour!e!um!QuackBehaviour!aos!quais!delega!as!capacidades!de!voar!e!grasnar.!


#3$Princípios$de$Projeto$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!define!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.!


Bibliografia$•  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

Education

Transcript of Aula 04 - UML e Padrões de Projeto