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

A GENDA Aumentando nosso exemplo (banco/empresa) Interfaces

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

A UMENTANDO NOSSO EXEMPLO ( BANCO / EMPRESA ) Classe Gerente

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

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.

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?

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

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.

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

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

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

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.

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

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.

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

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!

I NTERFACES Agora o Gerente pode assinar o contrato:

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.

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

I NTERFACES Agora podemos passar qualquer Autenticavel para o SistemaInterno.

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

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

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

REFERÊNCIA Apostila caelum-java-objetos-fj11