Prof. Me. Marcos Echevarria

Transcrição

1 Prof. Me. Marcos Echevarria

2 Grandes sistemas de software nunca são concluídos, eles simplesmente continuam evoluindo. Engenharia de Software 2

3 Engenharia de Software 3

4 Cada padrão descreve um problema que ocorre repetidas vezes em nosso ambiente, e então descreve o núcleo da solução para aquele problema, de tal maneira que pode-se usar essa solução milhões de vezes sem nunca fazê-la da mesma forma duas vezes Christopher Alexander, sobre padrões em Arquitetura Engenharia de Software 4

5 Engenharia de Software 5

6 Aprender com a experiência dos outros: Não é necessário reinventar a roda; Aprender boas práticas de programação: Padrões usam de forma eficiente herança, composição, agregação, modularidade, polimorfismo e abstrações para construir software reutilizável e eficiente; Melhora a comunicação/compreensão: Ajuda a entender o papel de classes do sistema; Melhora a documentação: Vocabulário comum Engenharia de Software 6

7 Engenharia de Software 7

8 Livro escrito por 4 autores, em 1994, conhecidos como: The Gang Of For O livro descreve 23 padrões, mostrando soluções genéricas para os problemas mais comuns de desenvolvimento; O sucesso veio da experiência dos autores, o que fez com que o livro se tornasse um clássico da literatura OO; Engenharia de Software 8

9 Engenharia de Software 9

10 Existem vários catálogos de padrões pra desenvolvimento de software, alguns são bem específicos: Padrões de implementação Java ou C# Padrões J2EE Padrões para concorrência Padrões para ambientes distribuídos Padrões JavaScript Etc; E também existem padrões mais gerais que se resolver qualquer problema em uma linguagem orientada a objetos; Engenharia de Software 10

11 Engenharia de Software 11

12 Engenharia de Software 12

13 Engenharia de Software 13

14 Imaginem que um cliente contratou vocês para implementarem um aplicativo que simule vários tipos de patos nadando em um lago; Engenharia de Software 14

15 Basicamente, podemos começar nosso sistema criando uma classe Pato; Após isso, podemos pensar em utilizar herança para começar a criar os vários tipos de patos que termos no sistema; O que vocês acham? Engenharia de Software 15

16 Pato +quack() +nadar() PatoBranco PatoCabecaVermelha Engenharia de Software 16

17 Pato +quack() +nadar() PatoBranco PatoCabecaVermelha E se nossos patos voarem? Engenharia de Software 17

18 Pato +quack() +nadar() PatoBranco PatoCabecaVermelha Engenharia de Software 18

19 Pato +quack() +nadar() Existe algum problema nisso? PatoBranco PatoCabecaVermelha Engenharia de Software 19

20 Pato +quack() +nadar() PatoBranco PatoCabecaVermelha Engenharia de Software 20

21 Pato Qual o problema? +quack() +nadar() PatoBranco PatoCabecaVermelha Engenharia de Software 21

22 Pato +quack() +nadar() Patos de borracha voam? PatoBranco PatoCabecaVermelha PatoBorracha Engenharia de Software 22

23 Engenharia de Software 23

24 Pato Voador +quack() +nadar() PatoBranco PatoCabecaVermelha PatoBorracha Engenharia de Software 24

25 Pato Voador +quack() +nadar() Qual o problema dessa solução? PatoBranco PatoCabecaVermelha PatoBorracha Engenharia de Software 25

26 Engenharia de Software 26

27 Identifique os aspectos da sua aplicação que variam e separe-os dos aspectos que permanecem iguais Engenharia de Software 27

28 Uma solução para esse problema seria programar para um interface, ou melhor, programar para um supertipo; A ideia é explorar o polimorfismo programando um supertipo de modo que o objeto de tempo de execução real não fique preso no código; Engenharia de Software 28

29 Pato +quack() +nadar() PatoBranco PatoCabecaVermelha PatoBorracha Engenharia de Software 29

30 Voadores VoaComAsas NaoVoa Engenharia de Software 30

31 Voadores Ok, mas como integramos isso? VoaComAsas NaoVoa Engenharia de Software 31

32 public class Pato { Voadores voadores; public void disparavoo() { voadores.voar(); } Pato +nadar() +disparavoo() } Engenharia de Software 32

33 public class PatoBranco extends Pato { } public void PatoBranco() { voadores = new VoaComAsas(); } Voadores VoaComAsas NaoVoa Engenharia de Software 33

34 public class PatoBorracha extends Pato { Voadores public void PatoBorracha () { voadores = new NaoVoa(); } VoaComAsas NaoVoa } Engenharia de Software 34

35 Engenharia de Software 35

36 Esse foi o padrão strategy; O padrão strategy define uma família de algoritmos, encapsula cada um deles e os torna intercambiáveis; O strategy deixa o algoritmo variar independentemente do cliente que o utiliza; Engenharia de Software 36

37 No nosso caso o cliente (Pato) utiliza uma família encapsulada de algoritmos para voar e granar (quack); Engenharia de Software 37

38 Engenharia de Software 38

39 Se em algum momento precisássemos criar patos que não fazem quack? Tipo um pato de madeira; Engenharia de Software 39

40 Crie uma nova classe para patos de madeira; Além desses patos não voarem, eles também não emitem som (não fazem quack ); Os patos de borracha também não fazem quack, porém eles emitem um som (tipo um apito); Os demais patos fazem o som de quack; Engenharia de Software 40

41 Engenharia de Software 41

42 Engenharia de Software 42