Boas práticas com Orientação a Objetos. Paulo Silveira

Transcrição

1 Boas práticas com Orientação a Objetos Paulo Silveira paulo.silveira@caelum.com.br

2 Rapidissímo overview IFs e switches X herança Vantagens e desvantagens do uso de Herança Casos errados do uso de herança Herança versus Composição Herança versus Interfaces Programando pensando em Interfaces

3 Antes de qualquer coisa: Não estou falando mal do seu código!

4 Switchs e IFs Usando polimorfismo

5 Caso trivial class Funcionario { private int codigo; public static final int DIRETOR = 1; public static final int PRESIDENTE = 2; //... public int getcodigo() { return this.codigo;

6 Em algum outro lugar.. class Relatorio { private double dinheirogasto; private Empresa empresa; //... public void adiciona(funcionario f) { switch (f.getcodigo()) { case Funcionario.DIRETOR : this.gastos += 1.1 * f.getsalario(); break; case Funcionario.PRESIDENTE : this.gastos += f.getsalario() + empresa.getpartedoslucros(); break; Esse tipo de código vai se espalhar por toda aplicação! Ao criar uma nova filha de Funcionario, precisamos mudar esse(s) código(s)!

7 Remodelando Funcionario class Funcionario { public double getgastos() { return this.salario; class Diretor extends Funcionario { public double getgastos() { return this.salario * 1.1; Diretor Presidente Cálculo dos gastos concentrado dentro da própria classe

8 E o relatório... class Relatorio { private double dinheirogasto; private Empresa empresa; //... public void adiciona(funcionario f) { this.gastos += f.getgastos(); Para adicionar uma nova classe que extende Funcionario, não teremos mais de mexer na classe Relatorio!

9 Controle de Permissões class Usuario { private int id; private String name; //... O uso de herança nesse caso é altamente dicutível! Moderador Usuario Administrador Estamos usando apenas como exemplo.

10 Primeira tentativa Ifs encadeados num estilo switch(int) public void apagaregistro() { if(this.user instanceof Usuario) { return false; if(this.user instanceof Moderador) { return false; if(this.user instanceof Administrador) { return true; Caso uma classe Colaborador fosse adicionada, precisaríamos mexer aqui também!

11 Usando polimorfismo Usuario Moderador Administrador class Usuario { public boolean hasright(int code) {

12 Apagando com a nova forma public void apagaregistro() { if(this.user instanceof Usuario) { return false; if(this.user instanceof Moderador) { return false; if(this.user instanceof Administrador) { return true; Passa para: public void apagaregistro() { if(this.user.hasright(permissions.delete){ return false;

13 E ao criarmos a classe Colaborador... class Colaborador extends Usuario { public boolean hasright(int code) { // monte de ifs e switchs Código de permissões não esta mais concetrado em um único lugar, cada classe é responsável pelo seu.

14 Pequena conclusão Switch é uma anomalia Polimorfismo é muito mais elegante Você muda apenas na própria classe, não precisa concentrar lógica de negócio. Switch é feio! Isto não é uma regra rígida!

15 Vantagens da Herança

16 Herança, quais são as vantagens? Reaproveitamento de código Possibilita polimorfismo Vamos mostrar que podemos ter esses benefícios de outras maneiras mais leves.

17 Quando não usar herança Apredendo com os erros da Sun

18 O que vocês acham dessas classes? java.util.properties java.util.stack

19 Properties public class Properties extends Hashtable Properties é uma Hashtable? Hashtable: associa Object Object Properties: associa String - String Properties não é uma Hashtable!

20 Properties Object Dictionary Hashtable Properties

21 O que acontece com esse código? Object object = new Object(); Hashtable table = new Properties(); table.put( x, object); table.get( x ); Funciona ok!

22 Um pouco pior... Object object = new Object(); Properties table = new Properties(); table.put( x, object); table.getproperty( x ); table.get( x ); Compila perfeitamente, mas só retorna o object quando chamado pelo.get, e pelo getproperty volta Null. Como adivinhariamos isso? Parece então que são duas tabelas separadas. Uma para Object- Object, e outra para String String

23 Último round Properties table = new Properties(); table.put( x, y ); table.getproperty( x ); Retorna null também? Não, dessa vez acontece o esperado.

24 java.util.stack Caso parecido Se é uma pilha, porque posso remove(int)? Porque posso add(int, Object)? Herdou apenas para não ter de escrever um vetor! PREGUIÇA!

25 Pequena conclusão Nunca usar herança quando a relação não é claramente é um. Contratos acabam sendo quebrados Difícil de mudar depois Pergunte a si mesmo se você não está fazendo isso por pura preguiça!

26 Lembram-se desse caso? Moderador é um Usuario? Usuario Usuario as vezes esta no papel de moderador ou administrador, mas a relação não é exatamente é um. Moderador Administrador

27 Classe Entity class Entity { private int id; private String name; private String description; // gets e sets class Usuario extends Entity { é um faz sentido? É um estado de Usuário? É um papel de Usuário? Veremos como resolver isso com composição!

28 Problemas trazidos pela herança

29 Considere Funcionario Diretor Presidente

30 Uso do protected class Funcionario { protected double salario; protected int idade; class Diretor extends Funcionario { public double getgastos() { if(this.idade < 35) { return salario; else { return salario * 1.1;

31 Uso do protected class Funcionario { protected double salario; protected int idade; O que acontece com a classe Diretor? Não compila? Isto não é o mais grave, ele poderia estar em outro jar, e ele vai começar a lançar Errors class Funcionario { protected double salario; protected Calendar nascimento;

32 Uso do protected Classe filha precisa conhecer bem a mãe Classe mãe não pode mudar sua representação interna com facilidade! Quebra de encapsulamento. Protected define um contrato forte para a mãe que não tem muito utilidade para quem esta de fora! Métodos protected não são tão malvados assim

33 Considere Pessoa Pessoa Física Pessoa Jurídica

34 Método na mãe muda Quando um método da mãe muda pode quebrar o comportamento da classe filha

35 Conhecemos a interface publica da classe class PessoaJuridica { public void adicionanota(nota nota) { public void adicionavariasnotas(list<nota> notas) { Não conhecemos bem essa classe!

36 Fornecedor quer saber quantas transcoes! class FornecedorJuridica extends PessoalJuridica { private int transacoes; public void adicionanota(nota nota) { this.transacoes++; Funciona? super.adicionanota(nota); public void adicionavariasnotas(list<nota> notas) { this.transacoes += notas.size(); super.adicionavariasnotas(notas); public int gettransacoes() { return this.transacoes; List notas =... // lista com 3 notas f.adicionavariasnotas(notas); f.gettotaltransacoes();

37 Depende! List notas =... // lista com 3 notas f.adicionavariasnotas(notas); f.gettotaltransacoes(); class PessoaJuridica { Resultado? public void adicionanota(nota nota) { this.vetorzinho[posicao++] = nota; public void adicionavariasnotas(list<nota> notas) { for(nota n : notas) { this.vetorzinho[posicao++] = n;

38 Mudança na classe mãe! List notas =... // lista com 3 notas f.adicionavariasnotas(notas); f.gettotaltransacoes(); E agora que mamãe mudou? class PessoaJuridica { public void adicionanota(nota nota) { this.vetorzinho[posicao++] = nota; public void adicionavariasnotas(list<nota> notas) { for(nota n : notas) { //... this.adicionanota(n); A resposta é 6!

39 Grande árvore de herança, mais problemas Pessoa Pessoa Física Pessoa Jurídica Fornecedor Físico Fornecedor Jurídico

40 Herança, lados negativos Você ganha mais coisas do que gostaria Sua relação com sua mãe é conturbada Quebra de encapsulamento Não use herança apenas por reaproveitamento de código da classe mãe! Não use herança apenas pelo polimorfismo!

41 Herança versus Composição Usando polimorfismo

42 Problemas! Além dos já apresentados: Pessoa Fornecedor é Pessoa? Pessoa Física Pessoa Jurídica Aqui tem código repetido! Fornecedor Físico Fornecedor Jurídico

43 FornecedorJuridico é Pessoa? É sim, mas estamos utilizando algo como Pessoa p = new Fornecedor()? Ou recebendo Fornecedor como Pessoa? Aumentado a hierarquia, como representaríamos alguem como Fornecedor e Consumidor?

44 Diminuindo acomplamento Pessoa Fornecedor Físico Pessoa Física class FornecedorFisico extends PessoaFisica { passa para: class FornecedorFisico { private PessoaFisica pessoa; // metodos para delegar

45 Acabando com código duplicado Pessoa Fornecedor Físico Pessoa Física Pessoa Jurídica Fornecedor Jurídico public String peganome() { public void envianotificacaosobrecredito() {

46 Acabando com código duplicado Pessoa Fornecedor Físico Pessoa Física Pessoa Jurídica Fornecedor Jurídico Fornecedor Helper

47 FornecedorHelper Faz o trabalho comum aos Fornecedores Pode ser uma classe package-friendly class FornecedorHelper { private String nome; private String ; public String peganome() { public void envianotificacaosobrecredito() { class FornecedorJuridico { private FornecedorHelper helper; public void envianotificacaosobrecredito() { this.helper.envianotificacaosobrecredito();

48 Vantagens do uso da composição Menor acoplamento, difícil de quebrar Quem faz e como faz esta escondido Implementação pode ser trocada em runtime

49 Antes de usar herança Estou fazendo por preguiça? É uma relação de é um? Não é um estado em que a classe pode ficar? Não é um papel que a classe pode tomar?

50 Será que isso pode causar transtornos? Object Component Container JComponent JPanel JSpinner.DefaultEditor JSpinner.DateEditor

51 Herança versus Interfaces Programando voltado para interfaces

52 E se eu precisasse de polimorfismo? Utilização de Interfaces Reaproveitamento por composição Classes abstratas na hora da preguiça! Talvez package-friendly

53 Entity como interface interface Entity { Entity int getid(); Usuario class Usuario implements Entity { //... public int getid() { return this.id;

54 Entity melhorada Entity Usuario EntityInfo class Usuario implements Entity { private EntityInfo info; public int getid() { return this.info.getid();

55 Temos de escrever o esqueleto sempre? Entity Abstract Entity EntityInfo Usuario

56 Regras do Gang of Four 1. Prefira composição em vez de herança 2. Programe pensando nas interfaces e não na implementação

57 Leitura recomendada Design Patterns, Gang of Four Effective Java, Joshua Bloch Refactoring, Martin Fowler

58 Obrigado! Perguntas e Respostas Você pode ver esta palestra em: Agradecimentos: Nos vemos no BrasilOne!