PROJETANDO CLASSES Dilvan Moreira (baseado no livro Big Java.

Apresentação em tema: "PROJETANDO CLASSES Dilvan Moreira (baseado no livro Big Java."— Transcrição da apresentação:

1 PROJETANDO CLASSES Dilvan Moreira (baseado no livro Big Java

2 Leitura  Capítulo 7 (1st Edition)

3 Objetivos  Entender:  Coesão  Acoplamento  Efeito Colateral

4 Lembrando: Herança  Herança: processo pelo qual estendemos uma classe existente para criar uma nova  princípio fundamental de POO  Subclasses herdam todas as variáveis da classe pai  Mas variáveis privadas não podem ser diretamente usadas pela classe filha

5 Lembrando: Herança public class CokeMachine2010 extends Cokematic { public void buyManyCokes(int num) {... }  Variáveis e métodos da classe Cokematic são incluidos na definição de CokeMachine2010  eles não aparecem na definição de CokeMachine2010, mas estão lá !  isso acontece por causa do comando extends

6 Lembrando: Polimorfismo  Capacidade de executar um método sem saber a que classe um objeto pertence  O que eu preciso saber sobre mymachines[i] ? for (int i = 0; i < mymachines.length; i++) { if (mymachines[i] != null) { mymachines[i].vandalize(); }  Herança + Method Overloading (substituição de método)  Uma das formas de implementar polimorfismo  Outra: Interfaces (veremos em breve)

7 Lembrando: Substituição de Métodos  Se uma classe filha define um método com a mesma assinatura que o pai: mesmo nome e parâmetros de entrada.  esse método da filha substitui o método do pai lembre: assinatura envolve número, tipo e ordem dos parâmetros

8 Lembrando: Substituição de Métodos  Se uma classe filha define um método com a mesma assinatura que o pai: mesmo nome e parâmetros de entrada.  esse método da filha substitui o método do pai lembre: assinatura envolve número, tipo e ordem dos parâmetros  Escrever seu próprio método toString() para uma classe substitui o método toString() herdado  Opps, herdado de quem?

9 Lembrando: Classe Object  Herdado de quem?  Em Java, todas as classes que não são explicitamente extendidas de outras classes são, por default, extendidas da classe Object A classe Object inclui o método toString()  assim... cabeçario de classe public class myClass  na verdade quer dizer public class myClass extends Object

10 Escolhendo Classes  Uma classe representa um único conceito de um domínio  O nome de uma classe deve ser um substantivo que descreve esse conceito:  Conceitos matemáticos: Point Rectangle Ellipse  Conceitos da vida real: BankAccount CashRegister

11 Escolhendo Classes  Atores (terminando em in -er, -or) – objetos que fazem algum tipo de trabalho para você Scanner Random // better name: RandomNumberGenerator  Classes utilitárias – sem objetos, apenas métodos estáticos e constantes Math  Iniciadoras de Programas – apenas tem o método main  Importante! Não transforme ações em classes: Paycheck é melhor que ComputePaycheck

12 Coesão  Uma classe deve representar um único conceito  A interface de uma classe é coesa se todas as suas funcionalidades estão relacionadas com o conceito que a classe representa

13 Coesão  Essa classe não tem coesão: public class CashRegister { public void enterPayment(int dollars, int{ quarters, int dimes, int nickels, int pennies)... public static final double NICKEL_VALUE = 0.05; public static final double DIME_VALUE = 0.1; public static final double QUARTER_VALUE = 0.25;... }  Por quê?

14 Coesão  CashRegister representa dois conceitos: caixa registradora e moeda  Solução: Faça duas classes: public class Coin { public Coin(double aValue, String aName){…} public double getValue(){…}... } public class CashRegister { public void enterPayment(int coinCount, Coin coinType) {... }... }

15 Acoplamento  Uma classe depende de outra se ela usa objetos dessa classe  CashRegister depende de Coin para determinar o valor de um pagamento  Coin não depende de CashRegister  Alto acoplamento = muita dependência entre classes  Minimize acoplamento para minimizar o impacto de mudanças nas interfaces das classes

16 Acoplamento: Diagrama de Classes  Para visualizar relações entre classes:  UML: Unified Modeling Language. Notation for object-oriented analysis and design

17 Acoplamento

18

19 Métodos de Acesso e Modificadores  Acesso: Não mudam o estado do objeto double balance = account.getBalance();  Modificador: modifica o objeto quando invocado account.deposit(1000);  Classe Imutável: não tem métodos modificadores String name= "John Q. Public”; String uppercased= name.toUpperCase(); //não muda  É seguro passar referências para objetos de classes imutáveis, já que nenhum codigo pode modifica-los.

20 Efeito Colateral  Efeito colateral de um método: qualquer modificação de dados observável externamente public void transfer(double amount, BankAccount other) { balance = balance - amount; other.balance = other.balance + amount; //  //Modifies explicit parameter }  Modificar um parâmetro explicito deve ser evitado, pois isso é geralmente inesperado podendo confundir outros programadores

21 Efeito Colateral  Outro tipo de efeito colateral é a saída de dados public void printBalance() // Not recommended { System.out.println("The balance is now $" + balance); }  Má ideia: mensagem é em inglês e usa System.out (e se quisermos imprimir em outro lugar?) É melhor desacoplar entrada/saída do código da sua classe  Minimize os efeitos colaterais

22 Linguagens Funcionais  Dados imutáveis + nenhum efeito colateral + código como dado = Programação Funcional  Linguagens Funcionais  Tem se apresentado como uma solução para Programação Concorrente em máquinas mult-core.  Exemplo: Erlang. Para a JVM: Scheme, Clojure  Java não é Funcional mas  Você pode adotar, sempre que possível, os princípios de classes imutáveis, ausência de efeitos colaterais e código como dados para melhorar seus programas.

23 Precondições  Precondição: Requisito que o chamador de um método deve obedecer  Precondições devem ser publicadas  usuários não chamarão os métodos com parâmetros incorretos /** Deposits money into this account. @param amount the amount of money to deposit (Precondition: amount >= 0) */

24 Precondições  Uso típico:  Restringir os parâmetros de um método  Exigir que um método seja chamado apenas quando o objeto está num estado apropriado  Se uma precondição é violada  o método não é responsável por fornecer o resultado correto, ele pode fazer qualquer coisa.

25 Precondições: Ações  O método joga uma exceção se uma precondição é violada – (mais sobre exceções no futuro) if (amount < 0) throw new IllegalArgumentException(); balance = balance + amount;  O método não testa a precondições (ele não é obrigado a testa-las. (Testar pode ser dispendioso) // if this makes the balance negative, it's the // caller's fault balance = balance + amount;

26 Precondições: Ações  O método pode fazer uma checagem de afirmação (assertion) assert amount >= 0; balance = balance + amount;  Para ativar: java -enableassertions MyProg Pode ser desligada depois da fase de testes  O método pode retornar silenciosamente (programadores novatos fazem isso) if (amount < 0) return; // Not recommended; // hard to debug balance = balance + amount;

27 Assertion assert condition;  Exemplo: assert amount >= 0;  Propósito: Testar que uma condição é satisfeita. Se testes de afirmação (assertion checking) estão abilitados e a condição é falsa, um asserion error acontece.  Por que esse teste pode ser desabilitado?

28 Poscondições  Condições que são verdadeiras depois que um método termina  Se a chamada de um método atende as suas precondições, ele tem que garantir que as poscondições sejam válidas

29 Poscondições  Existem dois tipos de poscondições:  O valor de retorno é computado corretamente  o objeto está num certo estado depois que o métodp termina  /** Deposits money into this account. (Postcondition: getBalance() >= 0) @param amount the amount of money to deposit (Precondition: amount >= 0) */  Don't document trivial postconditions that repeat the @return clause

30 Pre/Poscondições  Formule as pre- e poscondições em termos da interface da classe amount <= getBalance()// this is the way // to state a postcondition amount <= balance // wrong postcondition // formulation  Contrato: Se quem está chamando o método cumpre a precondição  o método tem que cumprir a poscondição

31 Métodos Estáticos  Todo o método deve estar numa classe  Um método estático não é chamado num objeto  Ele é chamado com o nome da classe em vez do objeto: double tax = Financial.percentOf(taxRate, total);  Uso principal: operações com tipos primitivos  O método main tem que ser estático pois ainda não existe nenhum objeto

32 Variáveis Estáticas  Pertence a classe. Também chamada variável de classe. public class BankAccount {... private int accountNumber; private static int lastAssignedNumber = 1000; } /* If lastAssignedNumber was not static, each instance of BankAccount would have its own value of lastAssignedNumber */  Minimize o uso de variáveis estáticas. (variáveis static final  ok.)

33 Variáveis Estáticas  Variáveis estáticas devem ser sempre private/protected  Exceção: Constantes estáticas: public class BankAccount {... public static final double OVERDRAFT_FEE = 5; // Refer to it as // BankAccount.OVERDRAFT_FEE }

34 Variáveis Estáticas

35 Perguntas ?