Quando usar Interaces?

Interfaces contém métodos (comportamento), não atributos. Pense eum uma interface como sendo um adjetivo ou um advérbio (algo que modifica um substantivo ou adjetivo) e nas classes como sendo substantivos.

No seu caso, não é possível definir uma interface Pessoa que tenha 2 atributos (pois Pessoa é substantivo) mas você poderia definir uma interface Professor (que é um qualificativo de uma pessoa), contendo por exemplo:

interface Professor {
    void ensinar();
}

Uma pessoa pode ser um professor:

class ProfessorDeEscolaEstadual extends Pessoa implements Professor {
    ...
}

Obrigado pela resposta entanglement.

Neste sentido pode-se dizer então que um interface são características específicas do objeto que será criado?
Digamos assim, se eu fosse criar uma classe Cadastro, ela necessitaria de um Interface?

Minhas dúvidas são bem essas, quando devo usar!

Ou até algo bem prático como por exemplo…

Voce utiliza DAOs?

Existe um pattern para DAOs em que criamos:

Uma classe GenericDAO que irá prover os CRUDs básicos (save, update, delete, list, etc)

Uma interface Repository

Interfaces para cada Bean por exemplo PessoaRepository que extende Repository

E finalmente a classe PessoaDAO que implementa PessoaRepository e pega os CRUDs de GenericDAO por delegação

No decorrer do sistema utilizamos somente PessoaRepository

A grande vantagem disso tudo é que podemos trocar a implementação de PessoaDAO o sistema não irá perceber.

Com isso é possível trocar um save via JDBC por um save via WebServices.

Confuso? rs…

(estou contando com a injeção de dependencia ok?)

luizpicolo:

Obrigado pela resposta entanglement.

Neste sentido pode-se dizer então que um interface são características específicas do objeto que será criado?
Digamos assim, se eu fosse criar uma classe Cadastro, ela necessitaria de um Interface?

A sua visão é restritiva de mais. “Quando num sistema de Cadastros usaria uma interface?”. Nunca. Até que vc precise dela.

O conceito de interface tem que ser entendido na sua forma abstrata e formal para depois poder ser usado. Ao contrário não funciona. Não é uma coisa que se aprenda com exemplos.

A interface , como o nome diz, representa uma visão do objeto. Uma perspectiva. Vários objetos diferentes podem apresentar a mesma perspetiva se olhados do angulo certo.
A prespetiva pode oferecer ou não métodos para interagir com o objeto e pode inclusive oferecer propriedades ( embora seja desacomcelhados por outros motivos que não interessam agora).

Vc usa a interface quando vc precisa usar objetos de classes diferentes mas que têm a mesma perspectiva.

A famosa frase “É passaro ? É um avião ? Não! é o Super-homem” revela isto. Estas três coisas são de classes diferentes. Mas todas elas mostram a mesma perspetiva : Poder voar. Ou dito de outra forma, Ser “Voador”.
Então se eu tiver 3 classes uma de Passaro, uma de Avião e outra de SuperHomem elas serão diferentes, mas se todas implementarem a interface “Voador” eu posso tratá-los da mesma forma.
Posso por exemplo criar um array de voadores e colocar os três lá dentro. Mas se eu criar um array de uma das classes, não posso por os objetos das outras.

Não confundir com “Interface Gráfica” mais conhecida como UI (user Interface). A palavra interface na linguagem java não tem nada que ver com a UI.

ccknccknor, por quanto não utilizo.

sergiotaborda: Sim, eu sei que minha visão esta restrita, por este motivo mesmo que estou aqui no grupo :D.

Os conceitos de Interface eu entendi bem por meio do Livro e do texto (ou apostila) que referenciei no inicio deste post. Só que as vezes me confundia se havia a necessidade de utilizar ou não. Porém agora, percebi, isso em uma visão um pouco superficial ainda, que Interface podem ser características comuns entre os objetos, como Voar citado pelo sergiotaborda.
Ou seja, todos voam, mas como voam e outra coisa .

Legal, mas outra coisa me intriga:
Neste tradução retirada desta post: http://docs.oracle.com/javase/tutorial/java/IandI/createinterface.html.

“Há uma série de situações em engenharia de software quando uma interface é importante para diferentes grupos de programadores que deverão concordar com um “contrato” o qual expõe a forma como o software fazer suas interações. Cada grupo deve ser capaz de escrever o seu código, sem qualquer conhecimento de como o código do outro grupo está escrito. De um modo geral, as interfaces são contratos.”

Quando eu crio um “contrato” para outra pessoa, isso tem um sentido, mas porque eu criaria um contrato para mim mesmo?
Ou em outras palavras, porque eu não poderia criar um método “voar” em cada classe?

Voce criaria o metodo voar na interface… sem se preocupar com como o objeto voaria…

entao cada um que dissesse que voa teria que implementar como!

Por exemplo se vc criar um super homem e disser q ele voa terá que implementar como!

A interface apenas garante que quem a implementa tenha que escrever o como para cada caracteristica herdada

Pro cara que projeta a arquitetura nao importa como ele voa… basta dizer que para concluir um processo ele necessita de um voador…

tipo public void concluiProcesso(Voador voador){};

se voce vai passar um SuperHomem ou um Passaro, pouco importa… pois ambos vao ter os metodos necessarios para concluir o processo…

vc começa a perceber que o sistema fica menos grudado… a interface ajuda diminuir o acoplamento…

cckncckn: valeu…

Por exemplo, posso criar uma interface autenticação, e dizer que:

public Professor extends Pessoa implements Autenticacao
{

}

Ou seja, eu imponho que determinados grupos devem ser autenticados, independente da forma que eles vão se autenticar?

luizpicolo:

cckncckn: valeu…

Por exemplo, posso criar uma interface autenticação, e dizer que:

public Professor extends Pessoa implements Autenticacao
{

}

Ou seja, eu imponho que determinados grupos devem ser autenticados, independente da forma que eles vão se autenticar?

Com a interface você se preocupa apenas com o que ele faz e não como ele faz. Não importa se ele vai somar 1 + 5 e depois logar no sistema ou se ele vai apenas logar no sistema. Isso não importa nem um pouco para o metodo que o chama. Tudo o que importa é que o objeto seja capaz de fazer isso.

sim… vamos dizer que a arquitetura necessita de Autenticacao… na verdade seria melhor ser um Autenticável… faz mais sentido…

Entao para login num sistema ele necessita receber um Atutenticavel… logo

public boolean login(Autenticavel a){};

E ao utilizar o metodo de login voce passa um Professor

e provavelmente esse Professor irá implementar algum método de autenticacao…

vamos dizer que os alunos autentiquem com login e senha direto na base de dados… mas que os professores autentiquem via integração com outra aplicação utilizando http…

pro cara que desenhou a arquitetura pouco importa como… importa que voce quando criou a classe professor muito tempo depois teve que manter seu código compativel ao sistema já existente…

ai voce começa a ver a força da interface…

entenderia melhor se eu soubesse explicar melhor…kkk

Agora sim, depois de vários questionamentos, posso dizer que compreendi.

Valeu a todos.