Notas de Aula 06: Programação para tipos versus Programação para interfaces

Transcrição

1 Notas de Aula 06: Programação para tipos versus Programação para interfaces Objetivos da aula: Compreender o uso e a vantagem da programação para tipos Compreender o uso e a vantagem da programação para interfaces Entender e aplicar o conceito de coerção (typecast) Entender e aplicar o operador instanceof Entender e aplicar o conceito de Generics Recordando... Na aula passada, empregando o conceito de herança e o uso da interface, criamos diversas subclasses que possuíam métodos e atributos específicos, mas que compartilhavam atributos e métodos descritos na classe Profissional. Para instanciarmos um objeto, primeiro declarávamos a variável pelo seu tipo, e instanciávamos, através do método construtor, a respectiva classe. O seu código, apesar de funcional, não é o mais reutilizável. Existem outras maneiras de se trabalhar com os objetos de uma classe... Programação para tipos Na aula passada, criamos uma classe Engenheiro que herdava da classe ProfissionalRemuneraçãoFixa. A classe Medico também herdava de ProfissionalRemuneracaoFixa. Do outro lado da estrutura hierárquica, a classe Vendedor herdava da classe ProfissionalRemuneracaoComissionada. Uma segunda estrutura hierárquica, proveniente dos exercícios da aula passada, tem como a classe Fatura o seu topo. As duas hierarquias estão conectadas pela Interfaces Pagamento e Identificacao. Para relembrarmos toda a estrutura, reveja o diagrama de classes:

2 Quer seja nos exemplos, quer seja nos exercícios, todas as vezes em que criávamos um novo objeto, nos víamos forçados a utilizar a seguinte estrutura: <NomeDaClasse> <nomevariavel> = new <NomeDaClasse>(); Por exemplo, para instanciar um objeto da classe Engenheiro, faríamos: Engenheiro eng = new Engenheiro(); Com dois profissionais e objetos distintos, teríamos, então, duas declarações:

3 Hemoterapeuta h1 = new Hemoterapeuta(" "," ",100000); Hemoterapeuta h2 = new Hemoterapeuta (" "," ",200000); O termo aplicado ao que fizemos se chama programação tipos. Isso porque, para declarar uma variável, fazíamos de acordo com o objeto que iria ser instanciado. Isso não está errado, mas essa forma de programação não aproveita os níveis de abstração que a Orientação a Objetos proporciona e nem o que o Java permite utilizar como recurso de programação. Quando utilizamos a programação para tipos, o nosso programa terá, em tempo de compilação, as construções necessárias para invocações do métodos corretamente. Ou seja, a sobrescrita de métodos (polimorfismo de sobrescrita) é resolvida em tempo de compilação. O que pode ser feito? Programação para interfaces Em Java, podemos declarar um supertipo (utilizar uma classe mãe) e instanciar uma classe filha. Este tipo de programação também é chamada de programação para interfaces e difere da abordagem já estudada e utilizada até o momento pois aumenta o nível de legibilidade e a reusabilidade do código. Nesta abordagem, as resoluções do polimorfismo acontecem em tempo de execução, olhando-se para o objeto efetivamente instanciado, não pelo tipo declarado. Nos nossos exemplos, os objetos da classe Hemoterapeuta podem ser declarados pela superclasse, a classe Medico. Já os objetos da classe Engenheiro podem ser declarados como ProfissionalRemuneracaoFixa. Medico med1 = new Hemoterapeuta(" "," ",100000); Medico m2 = new Hemoterapeuta (" "," ",200000); ProfissionalRemuneracaoFixa eng = new Engenheiro(); Agora, vamos subir ainda mais o nível de abstração. O que há de comum entre um objeto da classe Engenheiro e um objeto Hemoterapeuta? Todas, em algum momento, são subclasses da classe Profissional, que é o topo da hierarquia (desconsiderando a classe Object, é claro). Então, porque não declará-las pela sua superclasse maior?

4 Profissional prof1 = new Hemoterapeuta(" "," ",100000); Profissional prof2 = new Hemoterapeuta(" "," ",200000); Profissional prof3 = new Engenheiro(); Para os métodos herdados, fica óbvio a escrita do código. No entanto, para os métodos específicos da classe, o compilador não saberá informar se a chamada é correta. Por exemplo, se quiséssemos invocar o método setcrea() da classe Engenheiro, um erro nos seria apontado. Por que? Profissional prof3 = new Engenheiro(); prof3.setcrea( ): // Um erro será apontado. O analisador sintático executa sua tarefa com base no tipo declarado e não no objeto instanciado. Podemos forçar o analisador sintático a entender que na verdade aquilo é um objeto da classe engenheiro fazendo um typecast. Esta operação só é possível porque a classe Engenheiro é filha da classe Profissional. A estrutura de um typecast é: (NomeClasseCoercao)<nomeVariavel> = (NomeClasseCoercao)<nomeObjeto> Engenheiro eng = (Engenheiro) prof3; eng.setcrea( ); A pergunta que se faz é: para quê declarar prof3 pela superclasse? No fundo, talvez tenhamos que fazer tantas operações de typecast que não vale a pena fazer esta declaração pela superclasse. Sim, é verdade. Se a operação de typecast deixa de ser pontual, isso pode indicar não só um problema de programação, mas também de modelagem. Uma possibilidade para amenizar o typecast é fazê-lo de forma implícita: ((Engenheiro)prof3).setCrea( ); Menos uma referência, mas ainda assim, a consideração anterior prevalece. Não existe uma receita de bolo para estes casos. Devem ser considerados os aspectos positivos e negativos de cada caso. Ok, não faz sentido adotar a declaração para supertipos neste caso. Aliás, só podíamos fazer uma coerção porque neste trecho de código é possível presumir o seu tipo (Engenheiro). Como a declaração da variável foi feita na linha anterior, podíamos assumir qual é o objeto esperado naquela variável.

5 Mas, nem sempre isso é possível. Imagine se criássemos um método na classe Principal que exibisse na tela a identificação do profissional com base no seu tipo? Para um engenheiro, exiba o CREA. Para um médico, o CRM. Uma solução possível seria criar dois métodos distintos: um para o objeto da classe Medico e outro para o objeto da classe Engenheiro. Mas, a maioria das informações são as mesmas. Já que temos dois objetos do mesmo supertipo, então podemos nos utilizar disso na criação de um único método. Para saber de qual objeto se trata efetivamente (já que dentro do método não sabemos qual foi a sua declaração e portanto não sabemos qual o seu tipo) podemos utilizar a instrução instanceof e colocar as instruções adequadas: public void imprimir(profissional prof){ System.out.println(prof.getCpf()); if (prof instanceof Engenheiro){ System.out.println(((Engenheiro)prof).getCrea()); else{ System.out.println(((Medico)prof).getCRM()); Ocorre que nos exercícios anteriores você já resolveu este problema: colocou este mesmo método nas classes se utilizando do polimorfismo de sobrescrita. Eficiente e elegante. O método da Interface getidentificacao() é contratado pela classe Profissional. Como a classe Profissional é abstrata, a implementação dos métodos é postergada para as classes filhas. Para um médico, o retorno é o CRM; para um engenheiro, o CREA. public void imprimir(profissional prof){ System.out.println(prof.getCpf()); System.out.println(prof.getIdentificacao()); Ocorre que, mesmo nestes casos onde não se pode prever o tipo do objeto, utilizar o operador instanceof é mais um indicativo de que sua modelagem está com problemas e seu código está refém das operações quebra-galho (POG-Programação Orientada a Gambiarra). Ok, então vamos aumentar um pouquinho mais o nível de abstração. Pelo que vimos e fizemos, para imprimir a despesa de um profissional bastava chamar o método calcularremuneracao(), certo?

6 public void imprimir(profissional prof){ System.out.println(prof.getIdentificacao()); System.out.println(prof.calcularRemuneracao()); Certo. E se quiséssemos imprimir também a despesa com uma fatura (considere os atributos vencimento e valor), que é uma classe de uma estrutura hierárquica diferente da classe Profissional? A solução é estender o conceito para o nível da interface e utilizar o que é comum: o método calculardepesa(). Para isso, no entanto, devemos declarar a variável local do método imprimir como do tipo interface Pagamento. public void imprimir(pagamento pag){ System.out.println(pag.calcularDespesa()); Problema resolvido? Talvez. Se quiséssemos imprimir os valores dos objetos em particular, deveríamos apelar novamente para o instanceof. Ou quem sabe, melhor ainda, rever se a interface pagamento não pode conter todos os contratos que ambas as hierarquias de classes precisam - um modo sútil de burlar a falta da herança múltipla. Abstrações ainda maiores... Em todos os exemplos, exercícios e desafios, você lidou com domínios particulares: uma empresa de plano de saúde, um locadora de filmes ou uma oficina de carros. As classes que lidamos até o momento são chamadas de POJO (Plain Old Java Objects) algo do tipo Objetos Clássicos em Java e refletem atributos e operações de entidades de um domínio. Mas, não é só de classes POJO que se faz um sistema. Estruturas de dados, classes de conexão a um banco de dados, entre outras, fazem parte, com frequência, de classes que você terá que escrever (ou reutilizar). Já é sabido a esta altura que o Java não suporta herança múltipla. Imagine, então, que você quisesse criar uma lista encadeada (Argh! Estruturas de Dados de novo!) de vendedores. Uma solução é criar uma classe geral chamada de No (Node). Um nó tem como atributo o próximo objeto da lista. Para deixar o mais genérico possível, você declararia esse atributo como do tipo Object. As classes POJO herdariam da classe No, caso quisessem implementar uma lista encadeada. Veja, por exemplo, como seria uma lista encadeada de carros:

7 public abstract class No{ private Object prox; public Object getprox(){ return prox; public void setprox (Object prox){ this.prox = prox; public class Carro extends No{ private String cor; public void setcor(string cor){ this.cor = cor; public String getcor(){ return this.cor; public class Principal{ public static void main(string[] args) { Carro c1 = new Carro(); Carro c2 = new Carro(); c1.setcor("branco"); c1.setprox(c2); c2.setcor("preto"); c2.setprox(null); percorrerlista(c1); public void percorrerlista(object cabeca){ while (cabeca!= null){ System.out.println(((Carro)cabeca).getCor()); cabeca = (Carro)cabeca.getProx(); O problema dessa abordagem é a de que seria necessário um typecast para percorrer a lista, pois o tipo declarado foi o mais alto possível (classe Object). O ideal é que tenhamos uma maneira de explicitar, de maneira genérica, o comportamento de uma classe sem precisar fazer typecast durante o uso. O Java oferece o conceito Generics. Vamos, novamente, imaginar uma classe genérica chamada No (referência a um nó da lista encadeada). O nó agora será denominado como genérico através da diretiva <T>. O atributo prox (próximo) e o retorno também serão genéricos e vão variar de acordo com a

8 instância. A classe Carro, filha de No, deve ter uma referência para substituição da generalidade no momento da declaração da classe: public abstract class No <T>{ private T prox; public T getprox(){ return prox; public void setprox (T prox){ this.prox = prox; public class Carro extends No <Carro>{ private String cor; public void setcor(string cor){ this.cor = cor; public String getcor(){ return this.cor; public class Principal{ public static void main(string[] args) { Carro c1 = new Carro(); Carro c2 = new Carro(); c1.setcor("branco"); c1.setprox(c2); c2.setcor("preto"); c2.setprox(null); percorrerlista(c1); public static void percorrerlista(carro cabeca){ while (cabeca!= null){ System.out.println(cabeca.getCor()); cabeca = cabeca.getprox(); Desta forma, o typecast não é mais necessário. Generics é um assunto vasto e inclui o conceito WildCards. Esta não é uma necessidade imediata para compreensão da orientação a objetos e está destinada a desenvolvedores mais experientes. Portanto, este assunto será comentado com mais aprofundamento em outra oportunidade.

9 Exercícios 1) Na interface Pagamento criada na aula passada, adicione um atributo (público, estático e final) com o valor do imposto sobre operações financeiras. Este valor soma-se ao cálculo de despesas. Utilize-o na classe Profissional e Fatura. 2) Crie uma interface chamada CRUD. Declare quatro métodos com retorno void e sem parâmetros: buscar, inserir, alterar e excluir. 3) Faça com que a classe Profissional implemente esta interface. Cada método deve imprimir na tela o seu objetivo. Por exemplo, o método buscar deve conter o código System.out.println( Método de busca ); 4) Instancie os objetos na classe Principal como tipo CRUD. Utilize os typecast para conseguir utilizar os métodos que são particulares de cada objeto. 5) Na classe Principal, crie um método para imprimir o nome da classe utilizando o instanceof. Depois, crie outro método que, ao invés de utilizar o instanceof, utilize o método getclass().getcanonicalname(), proveniente da classe Object.