Herança multipla x interface?

Não definitivamente não é herança multipla. Apenas ajuda a solucionar algumas situações que seriam resolvidas com H.M. O principal objetivo da H.M. que seria herdar funcionalidades não será alcançado com a interface, nela vc precisará reimplementar o “mesmo código” todas as vezes q utilizar uma classe interface.

ou entao delegar o codigo para classes helpers… assim a HM fica totalmente substituivel, e voce ganha o que realmente importa : polimorfismo.

o que seria essas classes “helpers”? como implementa-las para gerar a herança multipla?

Usando inner types e aspectos (mais exatamente com o AspectJ) você pode simular herança múltipla em Java usando interfaces.

Mais ou menos, ne paulo…

Polimorfismo e herança de implementaçao resolvem problemas diferentes.

Interfaces sao para estabelecer contratos. Eh bem elgal, pena que faltam as asserçoes em java.

Com herança multipla voce resolve problemas de abstraçoes mistas. A maioria dos problemas comuns pdoe ser resolvida facilmente sem essa funcionaldiade, utilizando pesadamente delegaçao, mas alguns pontos nao. As coisas no mundo real tem herança multipla, e as vezes essa falta prejudica a modelagemd e um dominio.

De qualquer modo, eh um mecanismo complexo de implementar numa linguagem e complexo de ser usado corretamente.

Shoes

pcalcado:

Com herança multipla voce resolve problemas de abstraçoes mistas. A maioria dos problemas comuns pdoe ser resolvida facilmente sem essa funcionaldiade, utilizando pesadamente delegaçao, mas alguns pontos nao.

Que ponto nao? Delega, como voce disse…

Voce falou que heranca de implementacao resolve OUTRO problema… pra mim, heranca de implementacao soh te TRAZ OUTRO problema

Diga nao a heranca! (ok, eh facil falar).

pcalcado,

Gostaria de perguntar uma coisa, depois de ler o texto sobre contrato no seu post anterior. Anotações poderiam resolver o problema de verificação de valores de um contrato ?

Obrigado,

Márcio

Herança múltipla costuma ser implementada de maneira confusa na linguagem. Considerando o nível de mau uso que Java já tem, eu fico feliz em não ter mais esta possibilidade de cosntruir coisas estúpidas.

De qualquer forma, ignorando isso, basicamente com interfaces e excesso de delegação você vai ter um cenário parecido como exemplo idiota abaixo:

abstract class Telefone
{
    abstract void ligarPara(Telefone bParty);
}

interface TransmissorDeDados
{
    void transmitir(byte[] dados);
}

class Trasmissor
{
    void transmitir(Rede rede, byte[] d)
    {
        rede.enviar(d);
    }
}

class CelularGsm extends Telefone implements TransmissorDeDados
{
    Transmissor t = new Transmissor();

    RedeGsm redeGsm = new RedeGsm();

    void ligarPara(Telefone bParty)
    {
        Conexao cnx = redeGsm.ligar(this, bParty);
        //...
        //...
        //...
        cnx.fecharConexao();
    }

    public void transmitir(byte[] dados)
    {
        t.transmitir(redeGsm, dados);
    }
}

class TelefoneFixo extends Telefone
{
    RedeFixa r = new RedeFixa(this);

    void ligarPara(Telefone bParty)
    {
        Conexao cnx = redeFixa.ligar(bParty);
        //...
        //...
        //...
        cnx.fecharConexao();
    }
}

class Pda implements TransmissorDeDados
{
    Transmissor t = new Transmissor();

    public void transmitir(byte[] dados)
    {
        t.transmitir(redeGsm, dados);
    }
}

A delegação me obriga a criar uma classe encapsulando uma responsabilidade que deveria estar no próprio TransmissorDeDados, não em uma classe à parte cujo único objetivo é encapsular um algoritmo, sem estado, praticamente um ponteiro de função.

Foi um exemplo idiota, mas basta começar a modelar um domínio complexo que começam a surgir tantas delegações que fica difícil manter o controle. Você pdoe ter classes artificiais, como uma classe:

abstract class Celular extends Telefone implements TransmissorDeDados
{
    Transmissor t = new Transmissor();

    abstract void ligarPara(Telefone bParty);

    public void transmitir(byte[] dados)
    {
        t.transmitir(redeGsm, dados);
    }
}

Que não têm significado no domínio, mas facilitam a emulação de herança múltipla. Claro que semrpe vãoe xistir classes artificiais, mas diminuir o númerod estas é quase sempre uma prioridade,a te´para diminuir a explosão de classes.

Delegação deveria ser usada em casos como o pattern Strategy, quando a implementação pode mudar isso é parametrizável, não quando você quer implementar uma responsabilidade que é sua.

http://c2.com/cgi/wiki?MultipleInheritanceIsNotEvil

De qualquer modo, como falei, hoje eu consigo me virar com Java e herança simples, assim como com int e Integer sendo coisas diferentes e Generics sem reflection decente

Shoes

Oi,

Nunca pensei sobre isso… qual a sua sugestão?

Shoes

Levando em consideração que anotações viram “interfaces” em bytecode, vai dar no mesmo.