LINGUAGEM DE PROGRAMAÇÃO ORIENTADA A OBJETOS

INTERFACES

Prof. Thiago Pereira Rique

<thiagorique2011@gmail.com>

http://thiagorique.wordpress.com/

AGENDA

Aumentando nosso exemplo (banco/empresa)

Interfaces

AUMENTANDO 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

AUMENTANDO NOSSO EXEMPLO (BANCO/EMPRESA)

Classe Gerente

AUMENTANDO NOSSO EXEMPLO (BANCO/EMPRESA)

Perceba que o método autentica de cada tipo de Funcionario pode variar.

AUMENTANDO 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.

AUMENTANDO 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?

AUMENTANDO NOSSO EXEMPLO (BANCO/EMPRESA)

Possibilidade:

Não é uma boa saída. Por quê?

AUMENTANDO 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.

AUMENTANDO NOSSO EXEMPLO (BANCO/EMPRESA)

A classe FuncionarioAutenticavel.

AUMENTANDO NOSSO EXEMPLO (BANCO/EMPRESA)

As classes Gerente e Diretor estenderiam a classe FuncionarioAutenticavel.

AUMENTANDO NOSSO EXEMPLO (BANCO/EMPRESA)

Perceba que FuncionarioAutenticavel é uma forte candidata a classe abstrata. O método autentica poderia ser abstrato.

AUMENTANDO 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.

AUMENTANDO NOSSO EXEMPLO (BANCO/EMPRESA)

Como resolver essa situação?

INTERFACES

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.

INTERFACES

Nosso contrato:

Podemos criar este contrato em Java:

INTERFACES

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!

INTERFACES

Agora o Gerente pode “assinar” o contrato:

INTERFACES

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”.

INTERFACES

Agora podemos tratar um Gerente como sendo um Autenticavel (polimorfismo).

A utilização mais comum seria receber como argumento no nosso SistemaInterno.

INTERFACES

Agora podemos passar qualquer Autenticavel para o SistemaInterno.

INTERFACES

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

INTERFACES

E se quisermos que o Fornecedor tenha acesso ao sistema?

Quem escreveu o SistemaInterno só precisa saber que Fornecedor é Autenticavel. (desacoplamento)

INTERFACES

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).

REFERÊNCIA

Apostila caelum-java-objetos-fj11 http://www.caelum.com.br/apostilas/