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
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
olha o chucy ai
para isso criaram a implementação de interfaces
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.
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ó:
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).
“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 
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.
Mixins sao a heranca multipla sem a bagunca 
Tem em Ruby e Python, tambem, e usa-se bastante. Nunca ouvi falar de nenhum problema 
Mixins sao a heranca multipla sem a bagunca![]()
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:
Interfaces não te dão polimorfismo, apenas um contrato comum à determinados objetos.
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.
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.
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.
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.
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 
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 
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.
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]
O problema neste caso é que desde o início já se deturpou o conceito de interfaces.
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?
O unico q pode fazer herança multipla em java é o Chuck Norrys… ^^