N�o pode se pensar t�o simplificada em heran�a multipla. Heran�a 
muiltipla � um conceito muito complexo e a pessoa deve saber exatamente 
o que est� fazendo. Fazer um amfibio de carro e navio n�o daria certo 
mas poderia come�ar do quais propriedades de um carro vc quer que o 
amfibio tem e de quais do navio. Do navio vc provavelmente n�o quer mais 
do que o casco e do carro provavelmente so o chassis. Heran�a multipla 
deve ser algo que acontece com classes bem b�sicos e n� de classes 
complexos. U exelente exemplo � o iostream de C++:

foi criado uma classe stream, que nada mais faz do que abrir streams. 
Foi criado a classe istream que herda do stream e acresenta somente 
opera��es de input stream e foi criado a classe ostream que somente 
meixe com output e herda do stream. ai com heran�a multipla foi criado 
uma classe iostream que herda do istream e ostream e faz input e output 
para streams.

Paulo Simao wrote:

>PessoALL,
>Ontem eu estava discutindo com um amigo, que est� come�ando a desenvolver em
>C++. Ele me perguntou sobre heran�a m�ltipla em Java. (Estamos falando de
>conceitos, ok?).
>Ai eu coloquei para da seguinte forma (Exemplo Cl�ssico):
>
>"Suponha que vc tenha um carro e um barco. Se vc quer um carro-anf�bio,
>basta que vc crie uma classe filha de ambas.
>Por�m, sabemos que isso � conceitualmente errado.
>Para obter um carro anf�bio,  n�o nos basta juntar o conceito de carro com o
>conceito de navio.  Na verdade, temos uma lista de requisitos para que
>classifiquemos algo como barco, e uma segunda para que classifiquemos algo
>como carro.
>Para criarmos um carro-anf�bio portanto, devemos criar algo que (a� sim)
>preencha uma nova lista de pr�-requisitos, formada pela uni�o das duas
>anteriores. Da� sim, poderemos criar um "molde"(Classe/Implememta��o) de
>carro anf�bio, e permitir sua produ��o em massa (Inst�ncias/Objetos)."
>
>Ai vem minha pergunta, depois de contar essa hist�rinha, que eu refleti...
>Ser� que as pessoas n�o est�o acostumadas a programar de maneira muito
>simplista?
>Eu digo isso com base no descaso que as pessoas fazem do uso de interfaces.
>A eu ver , a programa��o processual (macro-programa��o) deve ser feita
>apenas a n�vel de interface, e as particulariza��es de um sistema, a� sim,
>implementadas em classes. Obviamente no final devemos implementar uma classe
>para fazer o papel de cada interface, mas ela s� preencher�
>(micro-programa��o) o esqueleto criado com as interfaces.
>
>Que vc's acham disso, na teoria e pr�tica?
>Vc's trabalhado assim?
>Em suma, vamos discutir o assunto?
>    []'s a todos
>        P.O.
>
>ps-> Desculpem  email longo.
>
>
>
>
>------------------------------ LISTA SOUJAVA ---------------------------- 
>http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP 
>d�vidas mais comuns: http://www.soujava.org.br/faq.htm
>regras da lista: http://www.soujava.org.br/regras.htm
>para sair da lista: envie email para [EMAIL PROTECTED] 
>-------------------------------------------------------------------------
>



------------------------------ LISTA SOUJAVA ---------------------------- 
http://www.soujava.org.br  -  Sociedade de Usu�rios Java da Sucesu-SP 
d�vidas mais comuns: http://www.soujava.org.br/faq.htm
regras da lista: http://www.soujava.org.br/regras.htm
para sair da lista: envie email para [EMAIL PROTECTED] 
-------------------------------------------------------------------------

Responder a