Interfaces

Java Eldar Membro desde: 02/08/2002 12:27:02 Mensagens: 0 Offline

Assunto: O que são interfaces? Isto não é difícil de aprender. O ponto é saber o porquê de usá-las.

Você pode ler este artigo na íntegra http://www.guj.com.br/java.artigo.123.1.guj
Por favor, coloque os seus comentários sobre este artigo aqui.

Esse tutorial é animal!
Vale a pena!!

Me esclareça uma dúvida. No exemplo das clinicas as interfaces devem conter os métodos que serão implementados nas classes Pessoa e Animal? É para isso que servem interfaces, contém uma lista de métodos obrigatórios para classes semelhantes? Valew.

Exatamente!!

Valew aí Rafael, mas surgiu outra dúvida.Quando eu faço isso:

Paciente p = new Pessoa();
Paciente a = new Animal();

E eu quiser utilizar um um metodo que só tenha na classe Pessoa eu preciso de um cast? Por exemplo:

public class Pessoa implements Paciente{

public boolean testePsicologico(char resposta){
//implementacao
}

}

quando eu usar p.testePsicologico('s'); o que acontece?

Faca o teste

. Da erro de compilacao, uma vez que o metodo "testePsicologico" nao existe na classe "Paciente", mas sim apenas na "Pessoa".

Rafael

Thread.start() Membro desde: 03/04/2003 14:19:51 Mensagens: 27 Offline

Colega Rafael,
Tenho uma dúvida com relacao a classe Pessoa, ela define novamente os atributos e metodos ja definidos em Funcionario?!? Posso declarar outros? Posso recodificar eles? Sao necessarios?

Antecipadamente, muito obrigado

Alguém saberia me dizer por que razão a herança múltipla seria prejudicial à elaboração de um software ? E qual a vantagem em se usar interfaces frente a herança multipla ?

oi Alexander

Esse eh um topico muito delicado, e que pode causar muita polemica.

Heranca, simples ou multipla, por si soh, quebra o encapsulamento. E porque?
Porque a classe filha precisa conhecer detalhes de _implementacao_ da classe pai, o que quebra o paradigba de OO. O paradigma de OO deixa bem claro que voce deve se preocupar com a interface da classe, isso eh, com o que ela faz, e nao se preocupar com como ela faz.

Recomendo como leitura o livro Design Patterns do Gof, que fala bastante em preferir composicao a heranca, e o Effective Java, que mostra _muitos_ bugs que nascem com a utilizacao de heranca.

Com certeza, com heranca voce escreveria menos codigo. Mas OO nao quer que voce escreve menos codigo, quer que voce escreve de maneira clara (streamline of code), e encapsulada (sabendo o que faz, e nao como faz).

Mas OO nao quer que voce escreve menos codigo, quer que voce escreve de maneira clara (streamline of code), e encapsulada (sabendo o que faz, e nao como faz)

Caro Paulo, eu pessoalmente discordo um pouco dessa opinião. Escrever menos código induz a menos erros. O reaproveitamento de código é de extrema importância para a criação de software de qualidade em "ambiente de produção". E nem sempre é necessário que a classe filha saiba detalhes da classe pai, alías, diria quase nunca - desde que a classe seja bem definida e estruturada.

O desenvolvimento hoje é infinitamente mais complexo que a 10 anos atráz. O reaproveitamento promovido pela hereditariedade é crucial para suprir as necessidades atuais. E não acho que a herança quebre o paradigma da OOP, pelo contrário, considero que seja o conceito básico acerca do assunto.

Mas claro, existem posições divergentes quanto a isso.

Quanto à herança múltipla, acho sim, que esta pode tornar muito complexo e instável o gerenciamento das classes filhas.

É isso! Valeu!

J2Alex wrote:
Caro Paulo, eu pessoalmente discordo um pouco dessa opinião. Escrever menos código induz a menos erros. O reaproveitamento de código é de extrema importância para a criação de software de qualidade em "ambiente de produção". E nem sempre é necessário que a classe filha saiba detalhes da classe pai, alías, diria quase nunca - desde que a classe seja bem definida e estruturada.

Oi Alex. Lendo um dos dois livros que eu recomendei, um deles do Joshua Bloch, da SUN, msotra como a gente rpecisa saber da classe pai e da filha quando a gente escreve uma classe voltada para a heranca. Ele mostra um classico exemplo, de voce tentando extender um java.util.ArrayList.

O livro diz que sempre a classe filha tem de saber como a classe pai, nao importa a situacao. Isso quebra o encapsulamento, que eh o apradigma OO.

Bem, sempre considerei escrever menos uma solucao pior, senao estariamos todos programando em perl

. Bricnaidera, mas reutilizar codigo por heranca eh uma pessima opcao, ja que voce pode ser quebrado nas proxima versoes da superclasse, ou mesmo sofrer muito se uma subclasse da sua classe voerrida um metodo da classe avo.

Alias, tudo isso que eu to falando eh meio um copy and paste do Effective Java e do Design Patterns. Quando chegar em casa eu pego umas citacoes interessantes a esse respeito. Eu considero muito esses dois livros porque tive muitos poblemas com heranca, e percebi que evitando heranca meu codigo eh mais limpo e menos acoplado. (baixo acomplamento, alta coesao!)

Paulo,

Porque a classe filha deve sabe como a classe pai foi implementada?

Effective Java, Joshua Bloch, pagina 71

"Unlike method invocation, inheritance breaks encapsulation"
E ele roubou essa frase de Alan Synder, na Conferencia de OOP, Sistemas e linguagens da AMC em 1986.

Ai ele vai e fala os argumentos que falei previamente. Veja a classe AbstractList (qquer abstract collection). A documentacao do javadoc deles tem um estilo completamente diferente: em vez de falar o que o metodo faz, ele fala, explicitamente, COMO ele faz, que metodo ele chama, de que variaveis protected ele depende. Porque? Porque a subclasse _precisa_ saber a implementacao da superclasse, ou vai fazer override de algo achando q outra coisa ia acontecer.

Design Patterns, Gang of Four, pagina 19:

"The style of reuse (composition) is called black box reuse, because no internal details of objects are visible."

Composition rulez!

. Ele continua e fala:

"Because inheritance exposes a subclass to detais of its parents implementation, its often said that inheritance breaks encapsultaion" na mesma pagina. E ele cita o mesmo autor da conferencia da ACM de 86.

Nao sei se deu para engolir, ou se esclareceu. Mas lendo esses capitulos desses livros por completo, eh um choque a primeira vez.

Bem, ainda não achei tão convincentes os argumentos... digo porque na prática, tenho várias classes criadas por hereditariedade que não fazem a mínima idéia do que as superclasses fazem...

Mas vou procurar estudar um pouco sobre o assunto e acho que vc realmente deva estar correto no que diz.

Valeu! Tenho aprendido algumas coisas interessantes com vcs.

[]´s

J2Alex wrote:Mas vou procurar estudar um pouco sobre o assunto e acho que vc realmente deva estar correto no que diz.

Lembre-se que aqui nao existe um correto e um errado, Eh tudo questao de design e boas praticas.

Creio que se as classes forem simples, e se voce tiver classes bastratas que voce soh faz override dos abstracts, nao haja problema. Mas se as classes nao forem simples, voce precisa comecar a tomar cuidado.

Se heranca esta funcionando 100% ai para voce, eh sinal que a classe pai foi desenhada com bastante cuidado. A classe Classloader eh um exemplo disso, ela ta cheio de metodo privado, que sao helpers internos, para nao haver chamada virtual quando a classe pai nao quer.

Notícias, artigos e o maior fórum brasileiro sobre Java