Trabalhando com Interfaces O grande estmulo ao uso de interfaces um dos pontos fortes do Java, infelizmente este conceito pouco

co compreendido, at mesmo entre programadores ?experientes?. Isto possvel porque utiliza conceitos de programao orientada a objetos que muitas vezes so deixados de lado por um grande nmero de programadores. De fato, para conseguir realmente compreender a utilidade (ou seria necessidade?) da utilizao deste recurso, preciso antes conhecer conceitos de programao orientada a objetos ( assustador o grande nmero de programadores que utilizavam Java de forma procedural). O conceito de Programao Orientada a Objetos deveria trazer inmeros benefcios aos programadores, mas infelizmente muitos deles no conseguem compreender completamente os conceitos envolvidos, e acabam no conseguindo adaptar-se totalmente, resultado: seus cdigos so totalmente mistos. Estes desenvolvedores muitas vezes vem diversos conceitos OO de uma forma distorcida: ?Muito trabalho para pouco benefcio? dizem, diante da idia de criar classes e mais classes para realizar tarefas que antes podiam ser feitas em um nico arquivo no muito grande. A idia aqui no abrir uma discusso sobre "diferentes tipos de programadores" e sim mostrar o motivo pelo qual muitos programadores conseguem compreender o recurso, mas no entendem porqu ou quando devem utiliz-lo. Para que algum consiga utilizar interfaces efetivamente necessrio antes de tudo algum conhecimento concreto de programao orientada a objetos. Este artigo no visa ensinar conceitos de OO, ao contrrio, assumimos aqui que voc j tem algumas noes este respeito. Interfaces x Classes Toda classe possui um propsito especfico e (muito provavelmente) se relaciona com outras classes, formando assim um sistema completo e funcional. Quando escrevendo uma classe, podemos separar seus mtodos em basicamente dois tipos: os de acesso pblico e os de acesso privado (esquea os modificadores de acesso intermedirios por hora). Quando um mtodo declarado pblico, significa que ele pode ser invocado por outros objetos, ao contrrio de mtodos privados que, geralmente, realizam tarefas ou processam informaes as quais dizem respeito apenas ao funcionamento interno da classe em questo. Tomemos como exemplo uma classe chamada Funcionario:
view plainprint?

1. public class Funcionario { 2. private String nome; 3. private String endereco; 4. private double salario; 5. 6. public String getNome() { 7. return nome; 8. } 9. 10. public String getEndereco() { 11. return endereco; 12. } 13. 14. public double getSalario() { 15. return salario; 16. } 17. 18. private void calculaSalario() { 19. // Busca valores do banco etc. 20. } 21. 22. private void atualizaDados() { 23. // Busca valores do Banco etc. 24. } 25. }

Analisando o cdigo acima nota-se que um objeto Funcionario se relaciona com outras classes

de trs maneiras: retornando seu nome, seu endereo e o valor de seu salrio (a partir dos mtodosgetNome(), getEndereco() e getSalario()). Aos outros objetos, pouco importa como o objeto calcula estes valores. Para esta camada ?pblica? dado o nome de interface do objeto. Ento, quando um objeto se relaciona com outro, ele no acessa seus recursos diretamente, mas sim atravs de sua interface. Obs.: O termo ?relacionar? refere-se capacidade dos objetos de ?transmitirem mensagens? entre si, ou seja, um objeto pode invocar mtodos em outro, desde que estes mtodos faam parte da interface daquele objeto. As vantagens deste conceito se revelam quando considerarmos a facilidade de manuteno, afinal, desde que a interface de um objeto no seja modificada (ou seja, desde que a assinatura de seus mtodos pblicos no mude) no h qualquer problema em alterar o funcionamento interno de uma classe (seus mtodos e atributos privados), pois isto no ir exigir qualquer alterao nas demais classes do sistema , que se comunicam apenas atravs das interfaces (uma vez que os mtodos com os quais ela se relaciona no foram modificados). Desta forma, utilizando a classe acima como exemplo em uma suposta migrao da base de dados dos funcionrios de um banco de dados para outro, as nicas alteraes necessrias nos cdigos do sistema sero as dos mtodosatualizaDados() e tambm calculaSalario(), que acessam diretamente as bases de dados, como os demais objetos no conhecem e no utilizam estes mtodos de qualquer forma, no h riscos em danificar a estrutura do sistema ao alter-los. Utilizando Interfaces em Java Java estendeu o conceito de interfaces um nvel ainda mais flexvel. Ao modelar um sistema, o desenvolvedor pode assim pensar apenas nas interfaces de seus objetos (ou seja, na funo de cada um deles, e no seu relacionamento com os outros). Criando assim uma camada extra de abstrao. Colocando em pratos limpos: O uso de interfaces faz com que voc pense em objetos e o relacionamento entre eles, construindo assim a ?planta? do sistema de uma forma consistente e clara, depois disso, basta comear a ?construo? seguindo os moldes j existentes. Agora que j conhecemos o conceito principal, podemos comear a escrever cdigo:
view plainprint?

1. public interface Funcionario { 2. public String getNome(); 3. public String getEndereco(); 4. public double getSalario(); 5. }

A sintaxe para definio de uma interface extremamente semelhante utilizada na definio de classes. Todos os mtodos em uma interface so implicitamente abstratos (o equivalente utilizar o modificador abstract em uma classe abstrata), e pblicos. Assim, a interface Funcionario representa um ?molde? de tudo aquilo que ser acessvel outras classes em um objeto do tipo Funcionario. Desta forma, qualquer classe que implemente esta interface, ser tambm considerada do tipo Funcionario (o efeito semelhante ao de sub-classear uma classe chamada Funcionario por exemplo). Interfaces no podem ter atributos (ou seja, variveis membro), mas podem, no entanto possuir constantes definidas (variveis que utilizam os modificadores static e final conjuntamente).
view plainprint?

1. public interface Funcionario { 2. public static final int FUNCIONARIO_GERENTE = 0; 3. public static final int FUNCIONARIO_VENDEDOR = 1; 4. // etc. 5. }

Uma vez definida, a interface compilada normalmente (um arquivo .class gerado, como se

fosse uma classe qualquer). A sintaxe para implementao de uma interface por uma classe a seguinte:
view plainprint?

1. public class Pessoa implements Funcionario { 2. private String nome; 3. private String endereco; 4. private double salario; 5. 6. public String getNome() { 7. return nome; 8. } 9. 10. public String getEndereco() { 11. return endereco; 12. } 13. 14. public double getSalario() { 15. return salario; 16. } 17. }

Uma classe pode ainda implementar mais de uma interface, neste caso, elas so colocadas lado a lado, separadas por vrgula juntamente com a clusula implements. Quando uma classe implementa uma interface, ela deve obrigatoriamente implementar os mtodos definidos na interface. O resultado que voc pode tratar objetos do tipo Pessoa como se fossem do tipo Funcionario. E com a possibilidade de a mesma classe implementar mais de uma interface, obtem-se um resultado semelhante ao de mltipla-herana, recurso inexistente na linguagem Java que permite uma classe ter vrias super-classes (ou seja, ela pode ser de vrios tipos diferentes). Assim, pode-se dizer que "uma pessoa um funcionario" e criar cdigos como:
view plainprint?

1. Funcionario f = new Pessoa();

O cdigo abaixo no est completo, mas exemplifica uma situao onde o uso de interfaces pode ser utilizado para criar uma situao semelhante de mltipla herana:
view plainprint?

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.

public interface Relogio { public String getHoras(); } public interface Radio() { public void liga(); public void desliga(); public void trocaEstacao(int frequencia); } public class RadioRelogio implements Radio, Relogio { private String horarioAtual; public RadioRelogio { // Inicializa objeto } public String getHoras() { return horarioAtual; } public void liga() { // Implementacao

24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. }

} public void desliga() { // Implementacao } public void trocaEstacao(int frequencia) { // Implementacao }

Um exemplo do mundo real Uma vez entendidos os mecanismos do funcionamento de interfaces, possvel partir para um exemplo realista, onde interfaces podem ser utilizadas no apenas para simplificar as coisas como tambm poupar um bocado de trabalho: Uma empresa de desenvolvimento de softwares possui um sistema utilizando em controle de clnicas mdicas de pequeno porte. O sistema relativamente simples, utilizado apenas para cadastro e controle de pacientes da clnica, mantendo um histrico do cliente, bem como informaes mdicas importantes. Em uma ocasio, a mesma empresa fechou um contrato para o desenvolvimento de um novo software para uma clnica recm aberta. A nica diferena que esta clnica era veterinria, lidava com animais e no com pessoas. No mundo real, as clnicas trabalham de uma forma totalmente diferente, mas falando em software, o funcionamento muito semelhante, quer dizer, a clnica veterinria tambm deseja manter histrico dos animais atendidos, bem como suas informaes mdicas (controle de vacinas etc.). Em suma, pode-se utilizar o sistema originalmente desenvolvido para clnicas gerais em clnicas veterinrias com algumas poucas adaptaes. A estrutura do sistema era a seguinte: O conjunto de classes acima foi criado para representar os pacientes de uma clnica, a classe PessoaJuridica utilizada para representar cadastros de convnios com empresas. O problema que animais possuem algumas caractersticas peculiares no possudas por pessoas, e viceversa. A soluo foi ento criar uma nova classe chamada Animal, para representar os animais da clnica:
view plainprint?

1. public class Animal { 2. // Informaes da Classe 3. }

Qual o problema aqui? O problema que outras classes do sistema possuam cdigos como este:
view plainprint?

1. public class Relatorios { 2. // ... 3. public void imprimeRelatorio(Pessoa p) { 4. // ... 5. } 6. // ... 7. }

Ou seja, seria necessrio alterar todas as classes para que recebessem como parametro um objeto da classe Animal. Obrigando assim a empresa a manter duas verses diferentes de um software extremamente semelhante, o que implicava em trabalho dobrado cada atualizao e/ou modificao. A soluo encontrada foi utilizar interfaces para realizar o que talvez

deveria ter sido feito durante a modelagem inicial do sistema. Percebeu-se que, do ponto de vista do sistema, tanto Pessoas quanto Animais eram Pacientes. Assim, reuniu-se todos os mtodos comuns pacientes (independentes de serem pessoas ou animais, e colocou-se em uma interface com este nome:
view plainprint?

1. public interface Paciente { 2. public String getNome(); 3. public Historico getHistoricoMedico(); 4. public Ficha getInformacoesCadastrais(); 5. // etc. 6. }

Tanto a classe Animal quanto a classe Pessoa so pacientes, logo, o nico cdigo que teve de ser acrescentado estas classes foi:
view plainprint?

1. 2. 3. 4. 5. 6. 7.

public class Pessoa implements Paciente { ... } public class Animal implements Paciente { ... }

Permitindo obter cdigos como:

view plainprint?

1. Paciente p = new Pessoa(); 2. Paciente a = new Animal();

Assim, ainda foi necessrio alterar no sistema, os cdigos que lidavam com objetos do tipo pessoa, para lidar agora com objetos do tipo Paciente. A vantagem que o mesmo sistema poderia ser utilizado tanto por clnicas mdicas quanto veterinrias sem causar um grande aumento de trabalho e eliminando a necessidade de se manter um sistema em separado.
view plainprint?

1. public class Relatorios { 2. // ... 3. public void imprimeRelatorio(Paciente p) { 4. // ... 5. } 6. // ... 7. }

A partir de agora, quando desenvolvendo um sistema, experimente pensar nos tipos que ira precisar (Pessoas, Cliente, Pacientes, Funcionarios etc.) crie suas interfaces e especifique o relacionamento entre eles. Voc com certeza notar que conseguir ver de antemo, muitos dos problemas de desenvolvimento que s seriam detectados no futuro, assim, quando tiver uma estrutura pronta, seu cdigo ficar muito mais limpo e claro.