Interfaces de Classe e Excessões
Carlos Andrés Ferrero
Material adaptado do curso de Desenvolvimento de Software em Java elaborado pelo Prof. Marcos André Pisching.
Problema
2
• Queremos projetar e implementar a parte d e autenticação do nosso sistema bancário.
Destrinchando a classe Funcionário, suponhamos o seguinte diagrama de classes.
Problema
3
• Acontece que apenas Diretores e Gerentes
podem fazer login no sistema interno do banco, os quais implementam o método autentica.
Problema
4
• Podemos pensar em algumas alternativas para tratar o problema em nível do sistema bancário:
Problema
5
• Podemos pensar em algumas alternativas para tratar o problema em nível do sistema bancário:
Problema
6
• Podemos pensar em algumas alternativas para tratar o problema em nível do sistema bancário:
Problema
7
• Podemos pensar em algumas alternativas para tratar o problema em nível do sistema bancário:
Problema
8
• Podemos pensar em algumas alternativas para tratar o problema em nível do sistema bancário:
Problema
9
• Podemos pensar em algumas alternativas para tratar o problema em nível do sistema bancário:
Problema
10
• Podemos pensar em algumas alternativas para tratar o problema em nível do sistema bancário:
Problema
11
• Uma solução mais próxima do correto seria utilizar conceito de Herança para essas duas classes:
Problema
12
Problema
13
• Muito bem!
• O problema parece estar Ok.
• Mas e se esse sistema do banco seria acessado também pelos clientes do banco (claro, com uma visão diferente)?
Problema
• Ficaria bom dessa forma?
Problema
Conceito
16
• As Interfaces são como contratos que são feitos pelas classes e que as mesmas devem cumprir. • Por exemplo, se construirmos uma Interface
“Autenticável” com uma assinatura para
autenticar, então todas as classes que assumirem o contrato e se dizerem “Autenticáveis” deverão escrever esse método.
Conceito
17
• Muito Importante: as interfaces apenas
consistem no que os objetos devem fazer e não como devem fazer, ou seja, não inclui
implementação dos métodos
• Vamos então refazer o nosso diagrama de classes, da seguinte forma:
Solução
Conceito
19
Conceito
20
Solução
21
Observações
22
• A classe cliente não foi implementada no exemplo anterior, mas pode ser implementada facilmente apenas fazendo a classe Cliente implementar
(implements) a interface Autenticável.
• Uma classe pode importar várias interfaces, ou seja, pode assinar vários contratos.
• Você não se preocupa com a natureza do objeto com que se interage durante o desenvolvimento, mas apenas com o que ele é capaz de fazer.
Exercício
23
• A partir da Interface AreaCalculavel
• Implemente Quadrado, Retângulo e
Tratamento de Exceções
24
• As exceções representam uma situação que
normalmente não ocorre e algo de estranho ou inesperado do sistema.
• Assim esses possível casos inesperados devem ser previamente tratados pelo programador.
• Essa situação requer de experiência e de conhecimento domínio do problema, pois devemos considerar erros que não são
detectáveis em tempo de programação e nem compilação.
Situação
Situação
Tratamento de Exceções
27
• Isso ocorre porque o método2 não trata a
situação “inesperada”; e isso também não foi feito pelo método1 e nem pelo main.
• A sequência de perguntas é:
– “o metodo2 está se precavendo de um problema
chamado ArrayIndexOutOfBoundsException?” Não.. – “o metodo1 está se precavendo de um problema
chamado ArrayIndexOutOfBoundsException?” Não.. – “o main está se precavendo de um problema
Tratamento de Exceções
28
• Inclusive podemos observar que não apareceu na tela a conclusão de cada método com suas
respectivas strings. Portanto, o programa terminou, o que não é muito desejável.
Tratamento de Exceções
29
• Inclusive podemos observar que não apareceu na tela a conclusão de cada método com suas
respectivas strings. Portanto, o programa terminou, o que não é muito desejável.
Tratamento de Exceções
30
• Tratamento com try catch, fora do for
Tratamento de Exceções
31
• Qual a diferença no resultado?
• Experimente colocar o try catch no método1 e retire do método1;
Tratamento de Exceções
32
• No decorrer da disciplina executamos várias operações, como por exemplo, em acesso a
banco de dados, em que o NetBeans solicitou que tratássemos uma exceção.
• Essas exceções são chamadas de checked ou
verificadas. Aquelas que não são solicitadas, mas que devem ser conhecidas são denominadas de
unchecked ou não-verificadas. (como
ArrayOutOfBoundsException ou ArithmeticException)
Tratamento de Exceções
33
Tratamento de Exceções
34
• A IDE irá solicitar que escolhamos:
– Add throws declaration:
Tratamento de Exceções
35
• Existe uma grande tentação em passar a
responsabilidade de tratar as exceções para “outros”, na volta da recursão.
• Não há regras específicas de onde tratar
exatamente cada exceção e depende da situação em que cada exceção pode ocorrer.
Tratamento de Exceções
36
• Podemos também criar classes de exceções, para tratar situações específicas. Por exemplo,
Tratamento de Exceções
37
• Utilizando uma classe de exceção em banco de dados:
Tratamento de Exceções
38
• Relação com Interfaces
– Em várias situações uma interface pode apresentar uma assinatura já com o throws, isso faz com que o método que instanciar um objeto que use essa
interface deverá tratar a exceção, não ficando de responsabilidade do método em si, diminuindo a quantidade de código em cada classe.
• E-mail – [email protected] • Website – http://sites.google.com/site/anfer86/ Contato 39
• Treinamentos Caleum. Interfaces. Disponível em:
http://www.caelum.com.br/apostila-java-orientacao-objetos/interfaces/
• Treinamentos Caleum. Exceções e controle de erros. Disponível em:
http://www.caelum.com.br/apostila-java-orientacao-objetos/excecoes-e-controle-de-erros/
Referências
