Interfaces

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

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 ?
[color=“blue”][/color]

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

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!

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”:

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.

Realmente eu tenho classes criadas por herança que funcionam muito bem - e não são classes simples.

Trabalho com programação a 15 anos. O problema é que nessa época comecei com linguagem procedurais… e parece que isso entranha na alma da gente :twisted: … hehe…

Algumas questões sobre “patterns” me fogem ao conhecimento mais profundo, eu confesso… Mas desenvolvo softwares OOP a pelo menos 6 anos com bons resultados, e nunca havia pensado em herança sobre estes aspectos… mas… legal… tem horas que realmente devemos levar isso em consideração.

Até mais amigo.

[pergunta idiota]

por q uma classe filha não deveria conhecer detalhes da classe pai, já q ela herda eles? Por q isso quebraria o encapsulmento?

[/pergunta idiota] :shock:

Lich King:

[pergunta idiota]

por q uma classe filha não deveria conhecer detalhes da classe pai, já q ela herda eles? Por q isso quebraria o encapsulmento?

[/pergunta idiota] :shock:

Pq uma classe que conhece detalhes de QUALQUER OUTRA classe quebra o encapsulamento

Muito bom o artigo! Eu estava meio perdido, mas agora compreendi como isso funciona… valeu!

Por isso eu digo: java é puramente OO?Não, mas o que nós tentamos como programadores é diminuir o estrago… :lol:

Isso não limita o reuso?
Não fica meio “errado” re-declarar todos os atributos comuns às classes Pessoa e Animal (nome, dataNascimento, sexo) ?

Não ficou muito claro pra mim o “conhecer detalhes da classe pai”.

Ótimo. Obrigado.
Estava precisando disso…

Não podemos criar uma interface com métodos estáticos?

Achei maneiro o tutorial, estava tentando enfiar a minha classe de conexão com o banco de dados dentro de uma interface, para que se caso eu troque para outro banco, não será necessário alterar muita coisa.
Porém a minha classe de banco usa alguns metodos estáticos…

valew man
grande tuto ele ajuda muito

Para quem não manja muito de interface esse tutorial vale a pena. Eu recomendo.
Dei uma olhada e abrange bastante sobre interfaces.