Orientação a Objetos. Fernando Camargo 5 de junho de 2017

Transcrição

1 Orientação a Objetos Fernando Camargo 5 de junho de 2017 ZG Soluções

2 Por que um tema tão básico?

3 Por que um tema tão básico? 1

4 Vantagens da Qualidade de Código

5 Tempo gasto com código de má qualidade Features 20.0% 80.0% Bugs 2

6 Tempo gasto com código de boa qualidade Bugs 25.0% 75.0% Features 3

7 Avaliando um Código OO

8 4

9 Repetição de código (DRY) Don t Repeat Yourself 5

10 Repetição de código (DRY) Don t Repeat Yourself Lógica duplicada deve ser eliminada via abstração 5

11 Complexidade de código int qtd = 0; Integer kicker = null; String carta = null; for(string c:cartas){ if(carta == null){ carta = c.substring(0, 1); kicker = this.getpeso(c.substring(0, 1)); qtd++; }else{ if(carta.equals(c.substring(0, 1))){ qtd++; }else{ carta = c.substring(0, 1); if(kicker == null){ kicker = this.getpeso(c.substring(0, 1)); } } } } if(qtd==4){ return kicker; } return null; 6

12 Complexidade de código 7

13 Acoplamento 8

14 Acoplamento Não existe zero acoplamento 9

15 Acoplamento Não existe zero acoplamento Baixo acoplamento alterações pontuais 9

16 Acoplamento Não existe zero acoplamento Baixo acoplamento alterações pontuais Alto acoplamento alterações em todo o código/em cascata 9

17 O que causa alto acoplamento? Classes sabem demais sobre as outras 10

18 O que causa alto acoplamento? Classes sabem demais sobre as outras Acesso direto de propriedades 10

19 O que causa alto acoplamento? Classes sabem demais sobre as outras Acesso direto de propriedades Construção de dependências 10

20 O que causa alto acoplamento? Classes sabem demais sobre as outras Acesso direto de propriedades Construção de dependências Uso de implementações ao invés de interfaces 10

21 O que causa alto acoplamento? Classes sabem demais sobre as outras Acesso direto de propriedades Construção de dependências Uso de implementações ao invés de interfaces Falta de organização estruturada das classes (separação de camadas) 10

22 Coesão Classes Baixa coesão múltiplos métodos com responsabilidades/tarefas não relacionadas 11

23 Coesão Classes Baixa coesão múltiplos métodos com responsabilidades/tarefas não relacionadas Alta coesão classe possui uma única responsabilidade/tarefa, com métodos relacionados a ela 11

24 Coesão Classes Baixa coesão múltiplos métodos com responsabilidades/tarefas não relacionadas Alta coesão classe possui uma única responsabilidade/tarefa, com métodos relacionados a ela Métodos Baixa coesão método realiza várias tarefas 11

25 Coesão Classes Baixa coesão múltiplos métodos com responsabilidades/tarefas não relacionadas Alta coesão classe possui uma única responsabilidade/tarefa, com métodos relacionados a ela Métodos Baixa coesão método realiza várias tarefas Alta coesão método com uma única tarefa, podendo chamar métodos que a complemente 11

26 Sintomas de Projeto de Classes em Degradação

27 Sintomas Rigidez: toda mudança causa uma cascata de mudanças subsequentes em módulos dependentes 12

28 Sintomas Rigidez: toda mudança causa uma cascata de mudanças subsequentes em módulos dependentes Fragilidade: mudanças acarretam em quebras em muitos lugares diferentes 12

29 Sintomas Rigidez: toda mudança causa uma cascata de mudanças subsequentes em módulos dependentes Fragilidade: mudanças acarretam em quebras em muitos lugares diferentes Imobilidade: impossibilidade de reusar módulos em outros projetos 12

30 Sintomas Rigidez: toda mudança causa uma cascata de mudanças subsequentes em módulos dependentes Fragilidade: mudanças acarretam em quebras em muitos lugares diferentes Imobilidade: impossibilidade de reusar módulos em outros projetos Viscosidade: fácil fazer a coisa errada e difícil fazer a coisa certa 12

31 Sintomas Rigidez: toda mudança causa uma cascata de mudanças subsequentes em módulos dependentes Fragilidade: mudanças acarretam em quebras em muitos lugares diferentes Imobilidade: impossibilidade de reusar módulos em outros projetos Viscosidade: fácil fazer a coisa errada e difícil fazer a coisa certa Complexidade desnecessária: muitos elementos inúteis ou não utilizados (dead code) 12

32 Sintomas Rigidez: toda mudança causa uma cascata de mudanças subsequentes em módulos dependentes Fragilidade: mudanças acarretam em quebras em muitos lugares diferentes Imobilidade: impossibilidade de reusar módulos em outros projetos Viscosidade: fácil fazer a coisa errada e difícil fazer a coisa certa Complexidade desnecessária: muitos elementos inúteis ou não utilizados (dead code) Repetição desnecessária: falta de abstração apropriada para evitar repetição de código 12

33 Sintomas Rigidez: toda mudança causa uma cascata de mudanças subsequentes em módulos dependentes Fragilidade: mudanças acarretam em quebras em muitos lugares diferentes Imobilidade: impossibilidade de reusar módulos em outros projetos Viscosidade: fácil fazer a coisa errada e difícil fazer a coisa certa Complexidade desnecessária: muitos elementos inúteis ou não utilizados (dead code) Repetição desnecessária: falta de abstração apropriada para evitar repetição de código Opacidade: código difícil de ser entendido 12

34 SOLID

35 Single Responsibility Principle 13

36 Single Responsibility Principle Uma classe deve ter um, e somente um, motivo para mudar. 14

37 Single Responsibility Principle Mudanças de requisitos mudanças nas responsabilidades 15

38 Single Responsibility Principle Mudanças de requisitos mudanças nas responsabilidades Classes com múltiplas responsabilidades: Múltiplos motivos de mudança 15

39 Single Responsibility Principle Mudanças de requisitos mudanças nas responsabilidades Classes com múltiplas responsabilidades: Múltiplos motivos de mudança Acoplamento das responsabilidades difícil alteração 15

40 Single Responsibility Principle Mudanças de requisitos mudanças nas responsabilidades Classes com múltiplas responsabilidades: Múltiplos motivos de mudança Acoplamento das responsabilidades difícil alteração Conclusão: uma classe deve ter uma única responsabilidade 15

41 Open/Closed Principle 16

42 Open/Closed Principle Entidades de Software (classes, módulos, funções, etc.) devem ser abertas para extensão, mas fechadas para modificação. 17

43 Open/Closed Principle Uma mudança deve resultar em uma cascata de mudanças em classes dependentes. 18

44 Open/Closed Principle Uma mudança deve resultar em uma cascata de mudanças em classes dependentes. Mudanças de requisito adição de código novo sem alteração de código existente 18

45 Open/Closed Principle Uma mudança deve resultar em uma cascata de mudanças em classes dependentes. Mudanças de requisito adição de código novo sem alteração de código existente Como? 18

46 Open/Closed Principle Uma mudança deve resultar em uma cascata de mudanças em classes dependentes. Mudanças de requisito adição de código novo sem alteração de código existente Como? Abstrações que permitam um grupo ilimitado de possíveis comportamentos classes abstratas e interfaces 18

47 Open/Closed Principle Uma mudança deve resultar em uma cascata de mudanças em classes dependentes. Mudanças de requisito adição de código novo sem alteração de código existente Como? Abstrações que permitam um grupo ilimitado de possíveis comportamentos classes abstratas e interfaces Novos comportamentos adicionados por herança ou implementação de interface 18

48 Open/Closed Principle Uma mudança deve resultar em uma cascata de mudanças em classes dependentes. Mudanças de requisito adição de código novo sem alteração de código existente Como? Abstrações que permitam um grupo ilimitado de possíveis comportamentos classes abstratas e interfaces Novos comportamentos adicionados por herança ou implementação de interface Classes dependem da abstração (fixa), não da implementação 18

49 Open/Closed Principle 19

50 Liskov Substitution Principle 20

51 Liskov Substitution Principle Uma classe base deve poder ser substituída pela sua classe derivada. 21

52 Liskov Substitution Principle Extensão do Open/Closed Principle 22

53 Liskov Substitution Principle Extensão do Open/Closed Principle Classes derivadas não podem alterar o comportamento de classes base 22

54 Liskov Substitution Principle class Square extends Rectangle { public void setwidth(int width){ this.width = width; this.height = width; } } public void setheight(int height){ this.width = height; this.height = height; } class LspTest { private static Rectangle getnewrectangle() { return new Square(); } public static void main (String args[]) { Rectangle r = LspTest.getNewRectangle(); r.setwidth(5); r.setheight(10); System.out.println(r.getArea()); // Resultado: 100 ao invés de 50 } } 23

55 Interface Segregation Principle 24

56 Interface Segregation Principle Muitas interfaces específicas são melhores do que uma interface única. 25

57 Interface Segregation Principle Interfaces poluídas prejudicam a coesão 26

58 Interface Segregation Principle Interfaces poluídas prejudicam a coesão Clientes não devem ser forçados a depender de interfaces que eles não usam 26

59 Interface Segregation Principle Interfaces poluídas prejudicam a coesão Clientes não devem ser forçados a depender de interfaces que eles não usam Dependência de interfaces gordas gera acoplamento entre implementações 26

60 Interface Segregation Principle Interfaces poluídas prejudicam a coesão Clientes não devem ser forçados a depender de interfaces que eles não usam Dependência de interfaces gordas gera acoplamento entre implementações Diferentes clientes (implementações com diferentes responsabilidades) diferentes interfaces 26

61 ERRADO! interface Worker { void work(); void eat(); } class FactoryWorker implements Worker { public void work() { /* implementation */ } public void eat() { /* implementation */ } } class Robot implements Worker { public void work() { /* implementation */ } public void eat() { /*??? */ } } 27

62 CORRETO! interface Workable { public void work(); } interface Feedable{ public void eat(); } class FactoryWorker implements Workable, Feedable { public void work() { /* implementation */ } public void eat() { /* implementation */ } } class Robot implements Workable { public void work() { /* implementation */ } } 28

63 Dependency Inversion Principle 29

64 Dependency Inversion Principle Dependa de uma abstração e não de uma implementação. 30

65 Dependency Inversion Principle Implementações de baixo nível podem ser alteradas 31

66 Dependency Inversion Principle Implementações de baixo nível podem ser alteradas Uso dessas implementações alto acoplamento alterações de dependentes 31

67 Dependency Inversion Principle Implementações de baixo nível podem ser alteradas Uso dessas implementações alto acoplamento alterações de dependentes Uso de abstrações de alto nível (interfaces) baixo acoplamento 31