La herencia simple
Es la que tienen todos los lenguajes orientados a objetos: heredamos los atributos de una sola clase padre, lo cual nos permite reutilizar código. Si fuera herencia múltiple, podríamos heredar de más de un padre.
Ejemplo de como se codificaría
La herencia múltiple, si fuera implementada en PHP, se codificaría de la siguiente manera:
class C extends A,B{
// código
}Donde la clase C hereda atributos y/o métodos de dos clases, A y B.
Por ejemplo, la clase "HombreLobo" puede heredar de la clase "Hombre" y de la clase "Lobo", pero el problema es que se pueden hacer tantas combinaciones que será difícil seguir y mantener un diseño de este tipo. Por eso muchos lenguajes no la implementan, no por un tema técnico, solo por un tema de salvaguardar la integridad del diseño.
¿Se puede hacer o no?
Por lo que he visto en varios lenguajes, la discusión legítima no es "si se puede hacer o no". En muchos casos no se implementa (como en Java, PHP, etc) porque habilitarla es un posible camino al desastre.
Verdaderamente no es problema técnico, o de evolución, es un problema de criterios de diseño "OO".
Herencia múltiple a través de interfaces
De todas formas siempre hay una puerta trasera: hacer herencia múltiple a través de interfaces; pero el sentido es distinto a hacerlo con clases. Las herencias de clases definen el "que son" y las interfaces agrupan clases que definen el "que hacen".
Las interfaces permiten pasar del estilo de diseño "orientado a la implementación" a uno "orientado a la interfaz", donde todas las clases acceden a servicios a través de interfaces que son implementadas por clases concretas. Y al no depender de clases concretas (solo de entidades abstractas) nuestro diseño será más reutilizable que el anterior.
El mayor problema
Los problemas más comunes que puede dar la implementación de herencias múltiples son las "colisiones de nombres" y la "herencia repetida".
Las colisiones se pueden dar cuando las clases empiezan a tener los mismos nombres en los métodos generando la duda de cual método debo usar de las dos clases y la herencia repetida es cuando nuestra clase hereda de dos clases que a sus vez son hijas del mismo padre, por lo cual estemos posiblemente heredando características repetidas.
¿Que sugieren las "Guias de Diseño OO"?
Y ya que estamos del tema "diseño", lo comento: las guías de diseño recomiendan que para una buena jerarquía de herencia:
- Se deben tener no más de 7 (+-2) niveles
- Las jerarquías "gordas y bajas" son síntoma de "poca especialización"
- Las jerarquías "altas y flacas" son síntoma de "excesiva especialización".
¿Si tantas recomendaciones existen para la herencia simple, que queda esperar para la herencia múltiple?
¿Y los grandes libros de Patrones de Diseño?
Hasta yo puedo crear un patrón y usar la herencia múltiple, pero eso no quiere decir que sea la mejor solución a un problema, ni que este pueda aplicarse en otros contextos (la esencia de los patrones).
Tomando como referencia un libro base reconocido mundialmente como es el GOF , donde ninguno de los patrones (de los 23) hacen uso de la herencia múltiple, y tampoco la sugieren, y menos, se quejan de su falta.
Los patrones de diseño son considerados la mejor "receta de cocina" para resolver un problema recurrente, con el mejor diseño posible, donde puede ser aplicado en otros contextos (concepto de patrón: "elemento reutilizable de experiencia y conocimiento").
No he leído hasta el momento en ningún texto que documente principios, sugerencias, guías o buenas prácticas de diseño la recomendación de usar la herencia múltiple. Es más, lo que he visto es todo lo contrario, hacen mucho hincapié en controlar el uso de la herencia simple, llegando a desaconsejar hasta la sobreescritura de los métodos por el hecho de "¿para que heredas si luego sobreescribes el comportamiento?".
Tampoco he leido que exista una discusión importante sobre el tema ni que hubiera una campaña para su uso. Creo que no se discute mucho el hecho de la "no conveniencia" del uso de la herencia múltiple.
Resumen Final
El tema va más allá del lenguaje, el problema no es si un lenguaje lo soporta o no, el problema es si se debe usar o no, y los efectos que pueden causar sobre nuestro diseño y su posterior mantenimiento.
Si observamos la evolución de los lenguajes podremos ver que cada vez se orientan más a seguir las pautas que se dictan en la esfera del diseño, y esto no es para extrañarse, la programación es solo una parte de todo el proceso de desarrollo de software.
Nota al margen: con respecto a mis conclusiones sobre la herencia múltiple, no son de mi exclusiva invención ni se me ocurrieron meditando bajo un manzano... luego de leer muchas opiniones al respecto que apuntaban a tratar el tema como si fuera solo una "evolución", o la visión completamente opuesta, que los nuevos lenguajes "la carecen" (como si estuviéramos hablando de una debilidad) fue que me puse a investigar y a tratar de discernir entre lo subjetivo y lo objetivo.
Y como se concluye en la discusión del foro, los lenguajes son herramientas que se deben ajustar a los criterios de un diseño.
Al final de cuentas, todo es una discusión de diseño OO, aprender a usar una herramienta y a no abusar de las posibilidades de la misma, lo que puede volverla en contra nuestra.
Artículo basado en una discusión originada en Foros del Web
Artículo relacionado
0 comentarios:
Publicar un comentario