El concepto básico de la herencia múltiple (HM)

INTRODUCCIÓN

El concepto básico de la herencia múltiple (HM) suena bastante simple: puede crear un nuevo tipo heredando de más una una clase base. La sintaxis es exactamente la que espera, y en la medida en que los diagramas de herencia sean simples, la HM puede ser simple también.

Herencia múltiple hace referencia a una característica de los lenguajes de programación orientada a objetos en la que una clase puede heredar comportamientos y características de más de una superclase. Esto contrasta con la herencia simple, donde una clase sólo puede heredar de una superclase.

Lenguajes que soportan herencia múltiple en su mayor parte son: C++, Centura SQL Windows, CLOS, Eiffel, Object REXX, Perl y Python.

La herencia múltiple permite a una clase tomar funcionalidades de otras clases, como permitir a una clase llamada MusicoEstudiante heredar de una clase llamada Persona, una clase llamada Músico, y una clase llamada Trabajador. Esto puede ser abreviado como MusicoEstudiante : Persona, Músico, Trabajador.

Ambigüedades

En la herencia múltiple aparecen ambigüedades, como en el ejemplo de encima: si la clase Músico heredaba de Persona y Trabajador, y la clase Trabajador heredaba de Persona. Existirían las siguientes reglas::

MusicoEstudiante : Persona, Músico, Trabajador

Músico : Persona, Trabajador

Trabajador: Persona

Si un compilador está mirando la clase MusicoEstudiante necesita saber si debe juntar las características iguales o si deben estar separadas. Por ejemplo, tendría sentido unir las características "Edad" de Persona para MusicoEstudiante. La edad de una persona no cambia si le consideras una Persona, un Trabajador o un Músico. Sin embargo, tendría sentido separar la característica "Nombre" de Persona y Músico si los músicos usan un nombre artístico diferente de su nombre real. Las opciones de juntar y separar son válidas según el contexto, y sólo el programador sabe qué opción es correcta para la clase que está diseñando.

Cada lenguaje de programación trata estos problemas de herencia repetida de diferente forma:

C++ requiere que el programador establezca de qué clase padre vendrá la característica a usar. Por ejemplo con "Trabajador::Persona.Edad". C++ no soporta herencia repetida explícita porque no habría forma de indicar qué superclase usar.

CLOS permite al programador control total del método de combinación, y si no es suficiente, el protocolo de metaobjetos ofrece al programador formas de modificar la herencia, envío de métodos, instanciación de clases, y otros mecanismos internos sin afectar a la estabilidad del sistema.

Eiffel permite al programador explicitar si junta o separa características que son heredadas de superclases. Eiffel juntará características automáticamente si tienen el mismo nombre e implementación. El programador tiene la opción de renombrar las características para separarlas. Eiffel también permite explicitar herencia repetida como A: B, B.

Logtalk soporta tanto interfaces como multi-herencia de implementación, permitiendo declarar alias de métodos que ofrecen renombrar y acceder a métodos que quedarían ocultados por el mecanismo de resolución de conflictos convencional.

Perl usa la lista de clases para heredar de una lista ordenada. El compilador usa el primer método que encuentra mediante búsqueda en profundidad por la lista de superclases.

Java, Nemerle, Delphi, C# y Objective-C no permiten herencia múltiple; esto hace que no haya ambigüedad. Sin embargo, permiten a las clases implementar múltiples interfaces.

Debate

Hay debate sobre si la herencia múltiple puede ser implementada de forma simple y sin ambigüedad. Con frecuencia es criticada por su aumentada complejidad y su ambigüedad, así como los problemas de versiones y mantenimiento que puede causar (a menudo resumido como el problema del diamante).1

Los detractores también señalan que hay problemas de implementación de la herencia múltiple como no ser capaces de explicitar herencia de múltiple clases y el orden de las semánticas de clase que cambian con la herencia. Hay lenguajes que solucionan todos los problemas técnicos de la herencia múltiple, pero el debate principal sigue sobre si implementar y usar herencia múltiple es más fácil que usar herencia simple y patrones de diseño de software.

Antes de C++, el lenguaje orientado a objetos más popular era Smaltalk. Smaltalk fue creado desde cero como un lenguaje orientado a objetos. A menudo se dice que es puro, mientras que a C++ se le llama lenguaje híbrido porque soporta múltiples paradigmas de programación, no sólo el paradigma orientado a objeto. Uno de las decisiones de diseño de Smalltalk fue que todas las clases tendrían solo herencia simple, empezando en una clase base (llamada Object - ese es el modelo para la jerarquía basada en objetos) [17] En Smalltalk no puede crear una nueva clase sin derivar de un clase existente, que es la razón por la que lleva cierto tiempo ser productivo con Smalltalk: debe aprender la librería de clases antes de empezar a hacer clases nuevas. La jerarquía de clases de Smalltalk es por tanto un único árbol monolítico.

Las clases de Smalltalk normalmente tienen ciertas cosas en común, y siempre tienen algunas cosas en común (las características y el comportamiento de Object), de modo que no suelen aparecer situaciones en las que se necesite heredad de más de una clase base. Sin embargo, con C++ puede crear tantos árboles de herencia distintos como quiera. Por completitud lógica el lenguaje debe ser capaz de combinar más de una clase a la vez - por eso la necesidad de herencia múltiple.

No fue obvio, sin embargo, que los programadores requiriesen herencia múltiple, y había (y sigue habiendo) mucha discrepancia sobre si es algo esencial en C++. La HM fue añadida en cfrontrelease 2.0 de AT&T en 1989 y fue el primer cambio significativo en el lenguaje desde la versión 1.0.[18] Desde entonces, se han añadido muchas características al Estándar C++ (las plantillas son dignas de mención) que cambian la manera de pensar al programar y le dan a la HM un papel mucho menos importante. Puede pensar en la HM como una prestación menor del lenguaje que raramente está involucrada en las decisiones de diseño diarias.

Uno de los argumentos más convincentes para la HM involucra a los contenedores. Suponga que quiere crear

...