Buscamos por todo el mundo online para de este modo traerte la respuesta a tu duda, en caso de dudas déjanos tu pregunta y te responderemos sin falta, porque estamos para servirte.
Solución:
La respuesta corta es: porque los diseñadores del lenguaje decidieron no hacerlo.
Básicamente, parecía que los diseñadores de .NET y Java no permitían la herencia múltiple porque razonaron que agregar MI añadió demasiada complejidad a los idiomas mientras se proporciona muy poco beneficio.
Para una lectura más divertida y profunda, hay algunos artículos disponibles en la web con entrevistas de algunos de los diseñadores del lenguaje. Por ejemplo, para .NET, Chris Brumme (que trabajó en MS en CLR) ha explicado las razones por las que decidieron no hacerlo:
Diferentes idiomas en realidad tienen diferentes expectativas sobre cómo funciona MI. Por ejemplo, cómo se resuelven los conflictos y si las bases duplicadas se fusionan o son redundantes. Antes de que podamos implementar MI en el CLR, tenemos que hacer una encuesta de todos los idiomas, descubrir los conceptos comunes y decidir cómo expresarlos de una manera neutral en el idioma. También tendríamos que decidir si MI pertenece a CLS y qué significaría esto para los lenguajes que no quieren este concepto (presumiblemente VB.NET, por ejemplo). Por supuesto, ese es el negocio en el que estamos como un tiempo de ejecución de lenguaje común, pero aún no hemos llegado a hacerlo para MI.
El número de lugares en los que la MI es realmente apropiada es bastante pequeño. En muchos casos, la herencia de interfaz múltiple puede hacer el trabajo en su lugar. En otros casos, es posible que pueda utilizar la encapsulación y la delegación. Si tuviéramos que agregar una construcción ligeramente diferente, como mixins, ¿sería eso realmente más poderoso?
La herencia de implementación múltiple inyecta mucha complejidad en la implementación. Esta complejidad afecta el casting, el diseño, el envío, el acceso al campo, la serialización, las comparaciones de identidad, la verificabilidad, la reflexión, los genéricos y probablemente muchos otros lugares.
Puedes leer el articulo completo aquí.
Para Java, puede leer este artículo:
Las razones para omitir la herencia múltiple del lenguaje Java provienen principalmente del objetivo “simple, orientado a objetos y familiar”. Como un lenguaje simple, los creadores de Java querían un lenguaje que la mayoría de los desarrolladores pudieran entender sin un entrenamiento extenso. Con ese fin, trabajaron para hacer que el lenguaje fuera lo más similar posible a C++ (familiar) sin trasladar la complejidad innecesaria de C++ (simple).
En opinión de los diseñadores, la herencia múltiple causa más problemas y confusión de los que resuelve. Entonces cortaron la herencia múltiple del lenguaje (al igual que cortaron la sobrecarga de operadores). La amplia experiencia en C++ de los diseñadores les enseñó que la herencia múltiple simplemente no valía la pena.
Herencia múltiple de implementación es lo que no está permitido.
El problema es que el compilador/tiempo de ejecución no puede averiguar qué hacer si tiene una clase Cowboy y una Artist, ambas con implementaciones para el método draw(), y luego intenta crear un nuevo tipo CowboyArtist. ¿Qué sucede cuando llamas al método draw()? ¿Hay alguien muerto en la calle o tienes una hermosa acuarela?
Creo que se llama el problema de la herencia del doble diamante.
Razón:
Java es muy popular y fácil de codificar debido a su simplicidad.
Entonces, lo que sea que los desarrolladores de Java sientan difícil y complicado de entender para los programadores, intentaron evitarlo. Uno de esos tipos de propiedad es la herencia múltiple.
- Evitaron los punteros
- Evitaron la herencia múltiple.
Problema con la herencia múltiple: Problema de diamantes.
Ejemplo:
- Suponga que la clase A se está divirtiendo con el método (). la clase B y la clase C se derivan de la clase A.
- Y tanto la clase B como la C anulan el método fun().
- Ahora suponga que la clase D hereda tanto la clase B como la C. (solo suposición)
- Crear objeto para la clase D.
- D d = nuevo D();
- e intenta acceder a d.fun(); => ¿llamará fun() de la clase B o fun() de la clase C?
Esta es la ambigüedad existente en el problema del diamante.
No es imposible resolver este problema, pero crea más confusión y complejidad al programador mientras lo lee.
Causa más problemas de los que intenta resolver.
Nota: Pero de cualquier manera, siempre puede implementar la herencia múltiple indirectamente mediante el uso de interfaces.