LINGUAGEM DE PROGRAMAÇÃO ORIENTADA A OBJETOS INTERFACES Prof. Thiago Pereira Rique

Apresentação em tema: "LINGUAGEM DE PROGRAMAÇÃO ORIENTADA A OBJETOS INTERFACES Prof. Thiago Pereira Rique"— Transcrição da apresentação:

1 LINGUAGEM DE PROGRAMAÇÃO ORIENTADA A OBJETOS INTERFACES Prof. Thiago Pereira Rique http://thiagorique.wordpress.com/

2 A GENDA Aumentando nosso exemplo (banco/empresa) Interfaces

3 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Considere a seguinte situação: um Sistema de Controle do Banco pode ser acessado, além de pelos Gerentes, pelos Diretores do banco. Classe Diretor

4 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Classe Gerente

5 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Perceba que o método autentica de cada tipo de Funcionario pode variar.

6 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Considere agora o SistemaInterno e seu controle: É preciso receber um Diretor ou um Gerente como argumento, verificar se o mesmo autentica e colocá-lo no sistema.

7 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Não podemos chamar o método autentica, pois nem todo Funcionario possui este método (haveria erro de compilação). O que fazer então?

8 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Possibilidade: Não é uma boa saída. Por quê?

9 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) De acordo com o slide anterior, cada vez que criarmos uma nova classe de Funcionario que é autenticável, teríamos que adicionar um novo método de login no SistemaInterno. Uma solução mais interessante seria criar uma nova classe no meio da árvore de herança.

10 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) A classe FuncionarioAutenticavel.

11 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) As classes Gerente e Diretor estenderiam a classe FuncionarioAutenticavel.

12 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Perceba que FuncionarioAutenticavel é uma forte candidata a classe abstrata. O método autentica poderia ser abstrato.

13 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Vamos a uma situação um pouco mais complexa: precisamos que todos os clientes tenham acesso ao SistemaInterno. O que fazer? Criar outro método login em SistemaInterno (Opção descartada!) Fazer uma herança sem sentido (comum entre os novatos na POO). (Opção descartada!) Cliente estende FuncionarioAutenticavel Cliente definitivamente não é um FuncionarioAutenticavel.

14 A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Como resolver essa situação?

15 I NTERFACES Precisamos encontrar uma forma de referenciar Diretor, Gerente e Cliente de uma mesma maneira (fator comum). Toda classe define: O que faz (assinaturas dos métodos) Como faz (corpo dos métodos) Podemos criar um contrato que define tudo o que uma classe deve fazer se quiser ter um determinado status.

16 I NTERFACES Nosso contrato: Podemos criar este contrato em Java:

17 I NTERFACES Tal contrato chama-se interface, pois é a maneira pela qual poderemos conversar com um Autenticavel. Quem desejar ser autenticável precisa saber autenticar dado um inteiro e retornando um booleano. Uma interface pode definir uma série de métodos (o que faz), mas nunca conter implementação deles (como faz). Métodos de uma interface são públicos e abstratos sempre!

18 I NTERFACES Agora o Gerente pode assinar o contrato:

19 I NTERFACES O implements pode ser lido assim: A classe Gerente se compromete a ser tratada como Autenticavel, sendo obrigada a ter os métodos necessários, definidos neste contrato.

20 I NTERFACES Agora podemos tratar um Gerente como sendo um Autenticavel (polimorfismo). A utilização mais comum seria receber como argumento no nosso SistemaInterno.

21 I NTERFACES Agora podemos passar qualquer Autenticavel para o SistemaInterno.

22 I NTERFACES Quando tivermos mais um funcionário com acesso ao sistema, basta que ele implemente esta interface para se encaixar no sistema.

23 I NTERFACES E se quisermos que o Fornecedor tenha acesso ao sistema? Quem escreveu o SistemaInterno só precisa saber que Fornecedor é Autenticavel. (desacoplamento)

24 I NTERFACES Lembrete: A interface define que todos vão saber se autenticar (o que fazer), enquanto a implementação define como exatamente vai ser feito (como fazer).

25 REFERÊNCIA Apostila caelum-java-objetos-fj11 http://www.caelum.com.br/apostilas/