Re:Heraça Múltipla

19 respostas
M

Suponha q vc herde de duas classes, e tais classes possuem métodos com os mesmos nomes e parametros ??? qual utilizar ???

outro problema é um chamado “Deadly Diamond of Death” … dê uma olhada no Google

19 Respostas

V

olha o chucy ai
para isso criaram a implementação de interfaces

javapaulomg

Como nosso caro “mvsoares” disse isso realmente pode acontecer o chamado "diamante da morte’, este nome pelo desenho formado entre a herança mutipla entre 04 classes, porem a melhor solução para este caso mesmo e a aplicação de interfaces as quais seriam como contratos de classe, e assim a classe “E-UM” interface, sendo desta forma podendo utilizar metodos e chamadas polimorficas, e facilitando tornando mais claro o processo de herança.

peczenyj

Todos os milhões de programadores java em todo o mundo não sentem falta.
Quem sente falta usa C++ ou outra linguagem para isso.

Sobre o Diamante, saca só:

http://www.objectmentor.com/resources/articles/javacpp.pdf

T

Eiffel tem herança múltipla (não tem interfaces, assim com o C++), mas usa um “quebra-galho” para evitar esse “Deadly Diamond of Death”. Ou seja, você especifica de que classe quer herdar um determinado método. (Pelo menos você pode especificar - no caso do C++ nem sei o que ocorre).

pcalcado

“Quebra-galho” nada, é uma técnica bem simples e válida.

E se programadores Java não sentissem falta de herança Múltipla não haveriam mixins em AOP :wink:

herançamúltipla tem suas utilidades e elas não são substituídas por interfaces. A grande maioria das coisas que um programador faz pode ser feita sem seu uso mas não existe porque ter aversão ao conceito.

cv1

Mixins sao a heranca multipla sem a bagunca :slight_smile:

Tem em Ruby e Python, tambem, e usa-se bastante. Nunca ouvi falar de nenhum problema :wink:

Kenobi

cv:
Mixins sao a heranca multipla sem a bagunca :slight_smile:

Tem em Ruby e Python, tambem, e usa-se bastante. Nunca ouvi falar de nenhum problema ;)

A técnica é um pouco diferente, se pensarmos está mais para agregação - > composição, do que herança, pois você terá as funcionalidades, mas não deixará de ser quem é, ou se tornar outra pessoa para ter tais.

Em Ruby você pode fazer uso da técnica de mixins com módulos por exemplo, mas sua classe não poderá ser polimórfica à que faz uso dos métodos.

Interface ainda pode te dar essa vantagem, você fará o uso de polimorfismo, mas terá mais trabalho, concordo, ao fazer um extract de uma classe concreta pronta, e implementar tais métodos numa outra…

Não tenho aversão à herança múltipla, mas pelos projetos que já peguei sem tal já tem muita gente fazendo besteira, imagina com o mecanismo implementado.
:twisted:

pcalcado

Interfaces não te dão polimorfismo, apenas um contrato comum à determinados objetos.

Kenobi

pcalcado:
Interfaces não te dão polimorfismo, apenas um contrato comum à determinados objetos.

Eu posso sim ter programação polimórfica através de Interfaces, restringindo o escopo do objeto às funcionalidades da mesma.

Como no clássico - List algumList = new ArrayList();

ou public List getList();

Defino uma interface para voltar qualquer objeto que implemente a interface List.

pcalcado

Você está certo na implementação de itnerfaces em java mas o meu ponto é que interfaces não servem para estabelecer polimorfismo.

O que você definiu foi um contrato que foi seguido pela ArrayList. Como em Java classes e contratos se confundem o tempo todo existe um comportamento polimórfico, mas este não é o objetivo da definição de uma interface. Interfaces não são (não deveriam ser utilizadas como, ao menos) gambiarras para herança múltipla, são contratos.

Fabricio_Cozer_Marti

As interfaces representam o polimorfismo em Java, mas o problema é que nas interfaces não existe implementação alguma, deve existir alguma classe (abstrata ou concreta) que irá realmente possuir o código da funcionalidade, então as interfaces passam a assumir um papel na maioria das vezes de Especificador de Implementação.

Kenobi

pcalcado:
Você está certo na implementação de itnerfaces em java mas o meu ponto é que interfaces não servem para estabelecer polimorfismo.

O que você definiu foi um contrato que foi seguido pela ArrayList. Como em Java classes e contratos se confundem o tempo todo existe um comportamento polimórfico, mas este não é o objetivo da definição de uma interface. Interfaces não são (não deveriam ser utilizadas como, ao menos) gambiarras para herança múltipla, são contratos.

Sinceramente estranho, você concorda com mixins, herança múltipla e não vê um o uso de interfaces para polimorfismo.

IMHO pessoalmente acho uma das boas caracaterísticas do java, pois posso criar uma aplicação com um certo grau de “reusabilidade”.

Cansei de ver projetos desenhados somente para o foco central do seu problema e se tivesse aberto um pouquinho mais o foco, o projeto poderia servir para atender outros problemas, muitas vezes até no mesmo segmento de negócios.

Interfaces são contratos sim, você garante a implementação, mas fazer o uso polimórfico também lhe garante que terá um objeto com “aquele” escopo outrora definido.

pcalcado

Como assim ‘concorda com mixins’? Mixins, como eu citei acima, são uma forma de se obtêr herança múltipla. É como utilizar C orientado a objetos, é possível mas a linguagem não foi feita para isso.

O que é uma boa característica do java, possuir interfaces? o que interfaces em java me trazem que uma classe abstrata em C++ não traria?

Ser projetado para ser extensível tem muito mais a ver com quem projeta do que com interfaces, classes ou coisa do genero.

Interfaces são contratos, devem ser usadas para contratos, mas você usa como der na telha. A Sun já fez besteira suficiente com Serializable e suas tagging interfaces irmãs para servir de mau exemplo :wink:

Kenobi

pcalcado:
Como assim ‘concorda com mixins’? Mixins, como eu citei acima, são uma forma de se obtêr herança múltipla. É como utilizar C orientado a objetos, é possível mas a linguagem não foi feita para isso.

O que é uma boa característica do java, possuir interfaces? o que interfaces em java me trazem que uma classe abstrata em C++ não traria?

Ser projetado para ser extensível tem muito mais a ver com quem projeta do que com interfaces, classes ou coisa do genero.

Interfaces são contratos, devem ser usadas para contratos, mas você usa como der na telha. A Sun já fez besteira suficiente com Serializable e suas tagging interfaces irmãs para servir de mau exemplo ;)

Tudo bem , entendi mal, achei que estava falando à favor dos mixins.

Realmente a sua utilização para polimorfismo exige cuidado, mas não sou tão conservador. Acredito no uso com inteligência dos recursos.

Quanto à interface Serializable, não entendi seu ponto, qual a cagada da sun ? PS: Não estou sendo irônico, apenas não entendi mesmo -> ignorância :slight_smile:

pcalcado

Pense bem, o que parece mais natural:

class Boo implements Serializable{
}

Ou

@Serializable
class Boo {
}

Interfaces foram muito usadas como metadados antes das annotations, o que sempre foi algo muito feio.

Kenobi

pcalcado:
Pense bem, o que parece mais natural:

class Boo implements Serializable{
}

Ou

@Serializable
class Boo {
}

Então, exatamente não consegui percerber onde a Sun cagou feio. Na época você não tinha Annotations, o conceito estava longe de entrar em pauta.

Resolver a situação com uma “tag” seria simples ao desenvolvedor.

Com o passar do tempo, os conceitos foram aprimorados, mas até aí, não vi como uma “cagada”.

Confunde um pouco o programador basic, pois não sabe a diferença entre interface e tags , mas até aí, tudo bem.

Interfaces foram muito usadas como metadados antes das annotations, o que sempre foi algo muito feio.[/quote]

pcalcado

O problema neste caso é que desde o início já se deturpou o conceito de interfaces.

G

Alguém poderia me ajudar nesse assunto?

Porquê a herança múltipla pode ser prejudicial? Quais os problemas que podem exitir com a sua utilização?

I

O unico q pode fazer herança multipla em java é o Chuck Norrys… ^^

Criado 7 de agosto de 2006
Ultima resposta 7 de ago. de 2006
Respostas 19
Participantes 11