leandros wrote:Motivo de Java não ter herança múltipla é por causa do efeito Diamante que pode acontecer no Design.

pcalcado wrote:Ahm.. não.

Interfaces são contratos. Uma interface não cria o relacionamento que existe entre uma classe e sua superclasse como obediência á Liskov Substitution Principle, uma classe abstrata sim. interfaces são recursos para garantir que classes possuam uma "interface" (uma API) comum.

pcalcado wrote:
Acho que você quis dizer composição e não acomplamento, certo? De qualquer modo, herança múltipla não implica emg randes hierarquias ou vice-versa.

AndrewAguiar wrote:Não ha erro algum na modelagem, e o fato de ele poder ser um ativo em determinada ocasião torna ele um ativo.

pcalcado wrote:Sobre Diamanete, isso é estupidamente simples de resolver com linguagens estaticamente tipadas: Exija do programador que informe qual implementação ele quer se não sobrescrever o método.

leandros wrote:Motivo de Java não ter herança múltipla é por causa do efeito Diamante que pode acontecer no Design.

4.2 Single Inheritance versus Multiple Inheritance de The Java Programming Language, 1a ed. de 1996 wrote:
This is commonly called "diamond inheritance", and there is nothing wrong with it. Many legitimate designs show this structure. The problems exist in the inheritance of implementation, when W's implementation stores some state. If class W had, for example, a public field named goggin, and if you had a reference to an object of type Z called zref, what would zref.goggin refer to? It might refer to X's copy of goggin, or it might refer to Y's copy, or X and Y might share a single copy of goggin because Z is really only a W once even though it is both an X and a Y.

Java uses the single-inheritance model of object-oriented programming to avoid such issues.

Single inheritance precludes some useful and correct designs. The problems of multiple inheritance arise from multiple inheritance of implementation, so Java provides a way to inherit a contract without inheriting implementation. The way is to declare as interface type, instead of a class type.

ViniGodoy wrote:..

http://archive.eiffel.com/doc/manuals/technology/bmarticles/joop/multiple.html wrote:
But what about name clashes?

Whenever you talk about multiple inheritance, someone is bound to ask sooner or later (usually sooner) what happens in the case of name clashes -- identically named features in two or more parent classes.

No doubt the question is legitimate, but the gravity with which it is asked -- as if it were a deep conceptual issue -- has been an unending source of bewilderment to me. I believe it is one of these cases in which if you only take a minute or two to pose the problem cleanly then the solution follows immediately. (If you don't, you can spend the rest of your life and ten PhD theses on the subject.)

Assume you are in the inheritance-based reusability business and combine classes from two software suppliers, say one in New York and one in London. Sure enough, one day you are going to run into the problem of combining two classes that both have a feature called foo, to use as example one of these nice evocative names that programmers are fond of.

But this is not a conceptual problem! It merely results from an unfortunate choice of names. If the parent programmers had chosen other names, differing by just one letter -- influenced perhaps by local conditions, they might have used zoo in New York and fog in London --, the problem would never have arisen.

This suggests the two key observations on this problem:

* First, it is purely a syntactical problem, due to conflicting name choices. It has nothing to do with the fundamental properties of the classes involved.
* Second, nothing is wrong with the parents; each is perfectly consistent as it stands. The "culprit" is the common heir, which tries to combine two classes that are incompatible as they stand. So the heir should also be responsible for the solution.

The Eiffel technique follows from these comments. We certainly don't want to leave any ambiguity; a class (which should be a clean implementation of an abstract data type) should present to its clients a clean and consistent interface. So if it inherits from two classes with an identically named feature and doesn't do anything about it, it is incorrect and will be rejected by the compiler with a message pointing to the ambiguity and saying in effect: "Won't you make up your mind? Do you want foo from New York or foo from London?" (The actual compiler message, needless to say, uses a more restrained tone.)

To overcome the situation, the designer of the common heir may use the straightforward Eiffel technique of renaming, as illustrated by the following example:


class SANTA_BARBARA inherit

LONDON
rename foo as fog

NEW_YORK
rename foo as zoo
feature
...
end -- class SANTA_BARBARA

Of course it suffices to rename one of the clashing features to remove the ambiguity.

Luca wrote:
Isto é história, não é especulação.

pcalcado wrote:
Acho que quase todo mundo já tinha lido esta desculpa do Gosling, Luca, o ponto é que ela é esfarrapada. Dá pra resolver o problema de maneira muito simples e o argumento contra herança multipla contraria boa parte da teoria de OOP, a questão é que balanceando a solução com os benefícios de heranca multipla provavelmente acharam que nao vale a pena.

ViniGodoy wrote:
Taí, concordo em gênero, número e grau.