HERANÇA MULTIPLA vs JAVA

Oi

Felipe, impossível esquecer conceitos de OO nesta hora… Mas vamos lá

Eu acho que esta foi uma caracterisca que o Java não implementou e que é ótima… O Uso de interfaces é lindo

T+

Na minha opinião o uso de interfaces cobre a falta da herança múltipla.
Acredito que a implementação de herança múltipla poderia trazer mais caos do que benefícios. Acredito que foi uma idéia muito inteligente dos criadores da linguagem na não implentação deste item da orientação a objetos.

Portanto, sou a favor da não implementação da herança múltipla em Java.

eu diria q as interfaces foram a maneira mais inteligente de sanar essa nojera… ehaeheaheah, po cara, na boa… interfaces são tudo.

Realmente com interfaces vc naum sente a necessidade de usar herança múltipla.

Abraços

Imaginem a seguinte situação (clássica) .

Possuo uma classe Carro que tem os metodos e atributos necessarios para funcionamento, como comportamentos {andar, parar, acelerar … } e atributos {rodas, motor, bancos … }, e possuo uma classe Barco que também tem comportamentos {navegar,acelerar,ancorar} e atributos {motor, hélice(s) … }.

No momento em que eu quiser criar um carro-anfíbio, segundo os conceitos de OO, poderei fazer como que ele, simplesmente, herde de Carro e Barco. Mas se eu for fazer em Java terei que implementar as Interfaces que definem os comportamentos de Carro e Barco, assim não reaproveito nenhum comportamento pois terei que implementar tudo.

Alguns podem dizer que podemos apenas declarar os métodos e colocarmos em nossa classe um Carro e um Barco para realizar os comportamentos desejados … mas nem sempre o resultado sai como queremos, e também pode ser muito trabalhoso pois imaginem uma classe como Component que possui 185 métodos declarados.

Eu precisei fazer isso recentemente, não eram 185 métodos mas ainda é deselegante.

até hoje as interfaces resolveram os meus problemas de herança multipla, mas no caso de muitos metodos, como foi citado, realmente fica complicado.

Herança multipla acaba que você vai ter várias classes numa hierarquia sem fim!
Prefiro o uso de interface, mesmo que tenha vários metodos depois, há alguns patterns que ajudam a estabelecer um melhor paradigma de programação nessa situação. Interface também não é para se usar sempre, tem que se pensar no POO, se sua classe poder vir a ser herdada por mais alguém posteriormente, ai sim, interface nela e a implemente depois!
Se ela for definitiva não há porque usar interface, então herde dela.

Interface resolve muitos problemas. Mas muitas vezes eh interessante reutilizar algumas implementacoes. Isso da pra fazer com uma combinacao de inteface + composicao. Ou entao, usar os conceitos da AOP…

“jeveaux”:

Oi

Felipe, impossível esquecer conceitos de OO nesta hora… Mas vamos lá

Eu acho que esta foi uma caracterisca que o Java não implementou e que é ótima… O Uso de interfaces é lindo

T+

Condordo que não podemos esquecer, por isso foi que eu disse aquecer…

Agora, pode me citar um exemplo onde o uso de Herança Multipla seja realmente necessário.

O problema é não ter a opção de usar herança múltipla. Se eu quisesse usar, não teria como.

Herança múltipla pode gerar designs toscos sim, mas isso é problema de quem desenvolve. Mau desenvolvedor consegue fazer tosquice com qq coisa.

Minha opinião é que a linguagem deveria dar a opção, implementa e usa quem quiser… (e souber!!!)

concordo com rmuliana.
uma coisa q nao curto muito em java é q aparentemente, os desenvolvedores da linguagem presumiram que quem fosse programar nela seriam criancinhas de 5 anos q precisam que o compilador segure na sua mão e vá te conduzindo durante todo o trajeto da codificação do seu programa.
é igual à possibilidade de escolher, por exemplo, passar um tipo primitivo por referencia(sem usar a gambiarra de array)… pode gerar problemas? sim, mas o programador que se vire com isso, ou então a obrigatoriedade de vc tratar certas exceções… eu ficaria feliz se desse um simples warning indicando q eu poderia tratar uma exceção, mas não, o safado nem compilar compila…

voltando ao assunto… eu discordo totalmente da ideia de interfaces substituir herança múltipla… pode até ser q quebre um galho, mas por exemplo, no caso do veículo anfíbio citado por alguém ae, seria mto mais pratico declarar public class VeiculoAnfibio extends Carro, Barco {…} doq usar interfaces

"…eu ficaria feliz se desse um simples warning indicando q eu poderia tratar uma exceção, mas não, o safado nem compilar compila… "

Tudo bem!

Mas se java não lhe travasse para não fazer tosquisses!!

Imagina com herança multipla, e esse caso ae q vc citou!!

Imagina vc ter q alterar esse código q outra pessoa fez!!! cruzes!!!

Acho que vc teria q aprender seria “linguagens” diferentes Java Tosco e Java “Travado”?!?!?!

Trabalho com .NET e J2ME, caros ler códigos em .NET q outras pessoas fizeram é um horror ele não te “trava” em alguns casos !!!

Vale lembrar que o java, apesar de ser “criado para criancinhas de 5 anos”, é uma das mais poderosas linguagens da atualidade.

A Herança Multipla foi deixada de lado tb pq a principal idéia era desenvolver softwares para Eletrodomésticos. Sendo assim seria muito poder de fogo para coisas mais simples. Lembrando que ná época ninguém esperava que o Java fosse ter tal repercussão no mercado, a ponto de chegar onde chegou.

hahahaa… é isso aí!!
o Java é tão esquema q educa o programador a parar de fazer tosquisses!

bom, então agora que viram que java é muito mais que programação para eletrodomesticos, e se esse foi mesmo o motivo para deixarem de lado a herança múltipla, entao poderiam adicionar agora

Isso seria muito bom, se eles adicionassem a Herança Multipla no Java.
Mas e quanto ao J2ME???

Mesmo que não seja apenas para eletrodomesticos, ainda é muito forte a utilização do Java em microembutidos como Palm, PDA’s, Celulares etc…

O que os programadores Java acham dessa idéia, de adicionar Herança Múltipla no Java?

Interessante essa discussão, olha o que achei na net :lol: :

Herança múltipla no Jurassic Park

Dinossauro é um Animal.
Sapo é um Animal.
Sapossauro é Animal, Dinossauro e Sapo ao mesmo tempo.

<blockquote>abstract class Animal {

abstract void talk();

}

class Frog extends Animal {

void talk() {

System.out.println(“Ribit, ribit.”);

}

}

class Dinosaur extends Animal {

void talk() {

System.out.println(“Oh I’m a dinosaur and I’m OK…”);

}

}

// Isso não compila em Java, claro, pois não suporta multipla herança

class Frogosaur extends Frog, Dinosaur {

}

</blockquote>

Agora, o problema:

Animal animal = new Frogosaur();
animal.talk();

O que diria nosso amigo Sapossauro? “Ribit, Ribit.” ou “Oh I’m a dinosaur and I’m OK…” ?

Parece que esse problema é conhecido como “Problema do diamante”, eu não conhecia. A causa do problema foi herança múltipla de implementação, mas Java oferece herança múltipla de interface, o que resolve o problema do diamante, e incrementa o polimorfismo do comportamento dos objetos.

O artigo referido tem muito mais coisa, vale a pena gastar o inglês:

hilmilho
no caso de métodos conflitantes, poderia ser usada a assinatura dos métodos para fazer a diferenciação(como quando vc define métodos com o mesmo nome e assinaturas diferentes em uma mesma classe, por exemplo)… se mesmo assim continuar em conflito(como no seu exemplo), o programa poderia nao compilar, ou entao poderia existir o recurso de fazer uma especie de casting especial para forçar a usar o método de uma determinada classe

feliperod
até agora não entendi qual o problema em se usar herança múltipla no j2me

“mmpaulo”:

hilmilho
no caso de métodos conflitantes, poderia ser usada a assinatura dos métodos para fazer a diferenciação(como quando vc define métodos com o mesmo nome e assinaturas diferentes em uma mesma classe, por exemplo)…

Provavelmente os métodos representam o mesmo comportamento. Diferenciá-los, como você disse nas entrelinhas, não seria possível em métodos sem parâmetros. Para métodos com um parâmetro, seria possível acresentar outro para diferenciar. Um desavisado poderia tentar remover esse parâmetro aparentemente inútil. Outra opção, em assinaturas com dois ou mais parâmetros, mudar a ordem dos mesmos. Talvez mudar o tipo de um parâmetro também ajude. Mas se acrescentarmos ali, além de Dinossauro e Sapo, mais alguns tipos de animais, essa diferenciação por assinatura vai ficando inviável. Acho que nisso o Java mandou bem.

dinossauro = (Dinossauro) sapossauro;

dinossauro.falar()

Aí seria preciso “jogar fora” a parte Sapo do objeto sendo ‘casteado’. me parece que em C++ é possível acessar o endereço de uma das classes componentes da herança múltipla. Interessante:

<blockquote>class A {…};

class B : public A {…};

class C : public A {…};

class D : public B, public C {…};

If you create an object of class D, that object may have up to five
different addresses, depending upon how its used:

D d; // create object of class D

D* p1 = &d; // p1 is address of D part of d

B* p2 = &d; // p2 is address of B part of d

C* p3 = &d; // p3 is address of C part of d

A* p4 = (B*) &d; // p4 is address of A part of B part of d

A* p5 = (C*) &d; // p5 is address of A part of C part of d
http://cpptips.hyperformix.com/cpptips/diff_address

dinossauro = (Dinossauro) sapossauro; dinossauro.falar() Aí seria preciso "jogar fora" a parte Sapo do objeto sendo 'casteado'.

public class B {
public void x() {
System.out.println("Método x da classe B");
}
}

public class C extends A, B {
...
}

----

public void metodoQualquer() {
C obj = new C();
obj.x();
}

/* Não compila, o compilador nao sabe se deve chamar o método x da classe A ou da classe B */

public void metodoQualquer() {
C obj = new C();
[A]obj.x(); /* Imprime "Método x da classe A" */
}
/* Aqui vc não transforma um objeto da classe C(A, B) em um objeto da classe A, desprezando a sua porção da classe B, mas instrui o compilador dizendo 'compilador, eu sei que existem dois métodos iguais nas minhas superclasses, mas eu estou explicitando que quero usar o método da classe A, sacou? */

mas reconheço q isso iria complicar muito se acontecesse algo assim, por exemplo:
uma classe A q implementa o método x()
uma classe B q implementa o método x()
uma classe C q estende A e B
uma classe D q implementa o método x()
uma classe E q estende C e D
a minha classe E tem 3 metodos x(), vai ficar complicado usar a sintaxe q eu sugeri para especificar qual método queremos usar.. até é possivel, mas fica mto feio, ainda mais se houvessem mais classes implementando o método x().

outra abordagem, é simplesmente nao compilar, uai...
com o uso de interfaces, pode ocorrer um conflito de métodos e o programa simplesmente não compila, pq com classes nao poderia ser igual?
[code]
interface InterfaceA {
public void x();
}

interface InterfaceB {
public int x();
}

public class MinhaClasse implements InterfaceA, InterfaceB {
/* Iae, como implementar o método x()?
Se eu tentar escolher apenas um, ou o da InterfaceA ou o da InterfaceB, o programa nao compila... se eu implementar os dois, tb não compila, pq vai ter dois métodos iguais, mudando apenas o tipo de retorno, e isso não basta para o compilador saber qual vc estará querendo usar em determinado momento.. */
}[/code]

"mmpaulo":

public void metodoQualquer() { C obj = new C(); [A]obj.x(); /* Imprime "Método x da classe A" */ } /* Aqui vc não transforma um objeto da classe C(A, B) em um objeto da classe A, desprezando a sua porção da classe B, mas instrui o compilador dizendo 'compilador, eu sei que existem dois métodos iguais nas minhas superclasses, mas eu estou explicitando que quero usar o método da classe A, sacou? */

Ok, realmente poderia ficar complicado. Aquele último código em c++ ele cria ponteiros pra "partes" da classe. Mas desse jeito aí é mais intuitivo.

"mmpaulo":

outra abordagem, é simplesmente nao compilar, uai... com o uso de interfaces, pode ocorrer um conflito de métodos e o programa simplesmente compila, pq com classes nao poderia ser igual?

interface InterfaceA {
    public void x();
}

interface InterfaceB {
    public int x();
}

public class MinhaClasse implements InterfaceA, InterfaceB {
    /* Iae, como implementar o método x()?
Se eu tentar escolher apenas um, ou o da InterfaceA ou o da InterfaceB, o programa nao compila... se eu implementar os dois, tb não compila, pq vai ter dois métodos iguais, mudando apenas o tipo de retorno, e isso não basta para o compilador saber qual vc estará querendo usar em determinado momento.. */
}

public void int x();

Em C++ quando uma classe herda de outras duas que possuem o mesmo método ela utiliza o método da classe que estiver declarada primeiro.

interface A {
	void teste();
}
	
interface B {
	int teste();
}
	
class C implements A,B {
	// Como resolver a implementacao dos Metodos A#teste() e B#teste() ???
}

Esse erro é bem clássico mesmo.

Isso implica que na hora de construirmos nossas interfaces, devemos prestar muita atenção no nome dos métodos. É claro que um projeto bem definido impediria esse erro. Mas supondo que tenha passado despercebido este erro, para resolver basta retirar a parte que implementa a interface B e mudar o nome do método no código da classe.

Pronto. Lembrando que uma interface é apenas um ferramente para melhorar a clareza e facilitar a documentação do código, porém não se faz necessária de forma nenhuma, podendo ser retirada sem maiores transtornos.

"Heber":

um problema clássico de interfaces:

interface A {
	void teste();
}
	
interface B {
	int teste();
}
	
class C implements A,B {
	// Como resolver a implementacao dos Metodos A#teste() e B#teste() ???
}

Nem sempre a interface resolve ... neste caso eu não poderia implementar as duas.

Heber, esse exemplo é o que mmpaulo deu também.

Veja só, A#teste() e B#teste() têem a mesma assinatura(nome do método, tipo e quantidade de parâmetros). Quando vocêm implementa as duas interfaces, a classe recebe os métodos das duas interfaces.
Só que quando o compilador vai montar esse método sai algo como:
void int teste()
Como um método só pode ter um tipo de retorno, dá erro. Mas sou da opinião que o erro é do programador.

O meu objetivo com esse exemplo foi mostrar que utilizando interface não da pra resolver todas as lacunas deixadas pela falta de herança múltipla.

“feliperod”:

Esse erro é bem clássico mesmo.

Isso implica que na hora de construirmos nossas interfaces, devemos prestar muita atenção no nome dos métodos. É claro que um projeto bem definido impediria esse erro. Mas supondo que tenha passado despercebido este erro, para resolver basta retirar a parte que implementa a interface B e mudar o nome do método no código da classe.

Pronto. Lembrando que uma interface é apenas um ferramente para melhorar a clareza e facilitar a documentação do código, porém não se faz necessária de forma nenhuma, podendo ser retirada sem maiores transtornos.

“mmpaulo”:

“feliperod”:

Esse erro é bem clássico mesmo.

Isso implica que na hora de construirmos nossas interfaces, devemos prestar muita atenção no nome dos métodos. É claro que um projeto bem definido impediria esse erro. Mas supondo que tenha passado despercebido este erro, para resolver basta retirar a parte que implementa a interface B e mudar o nome do método no código da classe.

Pronto. Lembrando que uma interface é apenas um ferramente para melhorar a clareza e facilitar a documentação do código, porém não se faz necessária de forma nenhuma, podendo ser retirada sem maiores transtornos.

discordo, cara…
tudo bem q pode-se tirar as interfaces e a gente se virar sem elas…
mas ‘sem maiores transtornos’ já é exagero…
só um exemplo: tenta imaginar o tratamento de eventos de uma interface grafica sem interfaces! tudo bem q ainda seria possivel trabalhar com os eventos, mas seria muito mais trabalhoso e ‘feio’

Feio eu posso até concordar, só que mais trabalhoso??? O trabalho seria o mesmo, mas o conhecimento do programador teria que ser maior.

Aliás, para tratar eventos seria até melhor, afinal de contas no caso do MouseListener não seria necessário fazer overriding de todos os métodos da interface (são 4 métodos, se me lembro bem), apenas escreveria o que vai ser usado.

Portanto trabalhoso, não. Seria mais limpo o código.

No entanto, minha intenção não foi desestimular o uso de interfaces, e sim apresentar uma solução para o problema proposto, caso dois métodos fosse iguais em duas interfaces diferentes, retira-se uma delas e deixa a outra. Simples né…

Mas as interfaces para tratamentos de eventos só são interessantes pq já vem no JDK, caso contrário seria um transtorno. Já pensou, ter que criar todas as interfaces de tratamentos de eventos? Seria mais fácil copiar o código.

“feliperod”:

Aliás, para tratar eventos seria até melhor, afinal de contas no caso do MouseListener não seria necessário fazer overriding de todos os métodos da interface (são 4 métodos, se me lembro bem), apenas escreveria o que vai ser usado.

“feliperod”:

Mas as interfaces para tratamentos de eventos só são interessantes pq já vem no JDK, caso contrário seria um transtorno. Já pensou, ter que criar todas as interfaces de tratamentos de eventos? Seria mais fácil copiar o código.

A Interface é tão importante quanto herança múltipla. Se não tivesse a Interface então teria que ter herança multipla para resolver milhares de problemas que iriam aparecer. Mas como foi adicionada as Interfaces então eles (SUN) não quiseram ter trabalho com a herança múltipla, visto que a implementação da JVM seria bem mais complicadas, assim como um monte de programadores que fazem “tudo no main” iriam querer utilizar a herança múltipla de forma errada não iam conseguir nem compilar o código e iriam desistir … Isso tornaria o Java bem menos popular, o que não é muito interessante.

Acredito que deveria existir herança multipla de classes por causa dos conceitos de OO.
E se alguém vem com o argumento: “Herança múltipla é muito falado mas ninguém em C++” ou “Nunca vi um programa em C++ utilizando herança multipla”.
Eu digo apenas o seguinte: “Como posso utilizar uma solução(função) que não está disponível?”

.

Quem precisa de heranca múltipla quando se pode escrever métodos sobrecarregados?! :razz:

Acho que ao garantir o polimorfismo de funcões e a possibilidade de se implementar múltiplas interfaces, o Java oferece uma solucão muito mais fácil para problemas que envolvem especializacão de classes.

Eu já vi heranca múltipla em Object Pascal e posso assegurar que não havia controle nenhum sobre as funcões que realmente se queriam implementar, ainda mais quando elas tinham o mesmo nome! :???:

Com isso, considero o recurso de interfaces uma grande sacada da SUN e que descarta qualquer solucão com heranca múltipla, embora despreze alguns conceitos da OO. Mas isso não é problema visto que a UML oferece todo suporte à representacão de classes que implementam interfaces.

mmpaulo escreveu:

de qualquer forma, ou vc cria interfaces só para tratamento de eventos, ou cria classes para isso. como nao existe herança multipla, vai de interface mesmo.
se não, vc poderia incluir qualquer objeto como um actionlistener de um jbutton(exemplo), mesmo que esse objeto não seja um listener válido, nao implemente o método actionPerfoemed(), oque iria dar um certo pau na hora que um actionEvent ocorresse nesse botão

Bem, agora vc chegou no ponto que eu queria. Foi exatamente o que eu disse, a diferença seria apenas que o programador teria que ter um conhecimento muito maior para manipular eventos. Isso daria mais mobilidade (o que é possível em alguns casos). O método actionPerformed() poderia ter um nome qualquer. Mas aí rola uma dúvida.

Qual a relação dos “escutadores” com as interfaces?

addMouseLister(this);

Isso ficaria normal?

como assim, qq nome?
o actionPerformed() tem q continuar se chamando actionPerformed(), para que o JButton(exemplo) saiba quel método chamar nos objetos q foram registrados como seus action listeners, quando ocorrer um action event.
É justamente pra isso que teria q ser usado interface ou classe para implementar os listeners de um determinado tipo de evento, pra padronização(se não seria inviavel o tratamento de eventos como é feito atualmente no swing, swt, …)

seria sintaticamente correto… mas seria mto inutil hehe
tipo assim:

public class ManiPuladorDeEvento extends ActionListener {

public ManipuladorDeEvento(JButton b) {

b.addActionListener(this);

}

public void actionPerformed(ActionEvent ae) {

…

}

}

a classe seria só isso…

se for pra fazer assim, entao é mais facil fazer logo:

JButton b = new JButton("…");

b.addActionListener(new ActionListener() {

public void actionPerformed(ActionEvent ae) {

…

}

});

justamente pra isso que teria q ser usado interface ou classe para implementar os listeners de um determinado tipo de evento, pra padronização(se não seria inviavel o tratamento de eventos como é feito atualmente no swing, swt, ...)

Exatamente. Padronização. Essa é a principal função das interfaces.

Já imaginou um programador Java ter que desvendar quais métodos foram usados para tratar um evento em um aplicativo feito por outro programador? Nisso eu aplaudo as interfaces.

seria sintaticamente correto.... mas seria mto inutil hehe tipo assim:

public class ManiPuladorDeEvento extends ActionListener {
public ManipuladorDeEvento(JButton b) {
b.addActionListener(this);
}
public void actionPerformed(ActionEvent ae) {
....
}
}
a classe seria só isso...
se for pra fazer assim, entao é mais facil fazer logo:
JButton b = new JButton("....");
b.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent ae) {
...
}
});

Não deu na mesma? as duas formas não estão corretas?
Mas e se eu tentar criar um método para manipular um determinado evento, sem ter que implementar um interface? Seria possivel?

algo como:

public class ManipuladorDeEvento{ 


   public void apertarBotao(String nome_botao) { 
        nome_botao= botao.label; //seria assim mesmo??? botao.label ???
        System.out.print("vc apertou: "+nome_botao);
   } 
}

A dúvida é: Como fazer pro java saber que apertei o botão??? E como dizer pro java que quando eu apertar o botão é pra executar esse método. Se isso for possível, então seria uma alternativa ao uso de interfaces. Lembrando que não sou contra o uso de interfaces, pelo contrário, sou muito a favor. Mas para fins de aprendizado vamos prolongar o assunto.

acho que nao dá pra fazer isso nao, cara.
talvez eu esteja errado, maaas:
o jbutton foi projetado para receber apenas objetos ActionListener(isso inclui classes que implemenem essa interface, ou que estendessem a classe ActionListener[isso no caso q foi comentado aqui… caso nao existissem interfaces]), e ao ocorrer um action event, chamar o método actionPerformed dos seus listeners.

É… acho que eu estou querendo uma flexibilidade impossível. Aliás, aí seria uma bagunça só. Cada programa teria um cara diferente.

Na verdade isso é um forma de mostrar a importância das interfaces. Pelo menos no fonte do java. Agora, em projetos novos, acho que são pouco usadas.

Alguém usa interfaces com freqüência?
Em todos o programas?
E pra Web, alguém usa?

Só pra constar.

PS. - Vou tentar achar um jeito de tratar eventos sem usar interfaces. Se alguém quiser ajudar seria uma ótima maneira de aprender os fundamentos do java. Qualquer novidade postem aqui.

“feliperod”:

Alguém usa interfaces com freqüência?
Em todos o programas?
E pra Web, alguém usa?

As primeiras classes que eu implemento em um projeto são as interfaces.

Eu uso direto, sem exceções … pra quem já jogou algum dos meus jogos (MoveBlocks ou PontoAPonto) e viu os códigos, percebeu a quantidade de interfaces que eu tenho não só para eventos mas também para classes de negócios.

“feliperod”:

PS. - Vou tentar achar um jeito de tratar eventos sem usar interfaces. Se alguém quiser ajudar seria uma ótima maneira de aprender os fundamentos do java. Qualquer novidade postem aqui.

Eu uso interfaces principalmente em objetos que prestam serviços pela Web. Tem muito método que pode ser compartilhado e aí eu procuro organizá-los em interfaces de acordo com as suas funções.

Eu uso interfaces mais como uma “biblioteca de operações”. Fica melhor depois pra documentar as funcionalidades de um determinado objeto, pois sabendo quais interfaces ele implementa automaticamente você consegue imaginar o seu alcance.