Upload
internet
View
107
Download
0
Embed Size (px)
Citation preview
LINGUAGEM DE PROGRAMAÇÃO ORIENTADA A OBJETOS
INTERFACES
Prof. Thiago Pereira Rique
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/