Herencia simple vs herencia Multiple

Es como si se hubieran enfrentado a la imposibilidad de la herencia
múltiple y se decantaran por eso.

Eso se puede jurar. :)

Una solución a la herencia múltiple es la agregación. Para el ejemplo que
has puesto, y de nuevo en C#, la idea sería definir un interfaz para la
clase de los métodos comunes, luego definir una clase general que
implemente dicho comportamiento y que reciba una referencia a los
elementos que ha de modificar. Luego, en cada clase en donde hubieras
debido hacer herencia múltiple, declaras una instancia a esa clase
general... y si necesitas cambiar el comportamiento de algún método de esa
clase general, pues heredas otra nueva clase general y listo.

Que interesante idea!

Muchas gracias

El Thu, 30 Oct 2008 08:08:00 -0400, Luisa Goicochea escribió:

Igual, desde mi punto de vista, la herencia múltiple es buena, sin embargo,
sólo para aquellos que la sepan manejar.

Hasta la herencia simple es para quien la sepa manejar :)

Buen punto :-), y hasta los ordenadores también :-)

Hola RFOG,

El Thu, 30 Oct 2008 13:26:24 +0100, RFOG escribió:

Buena respuesta la de Alberto, pero eso, como diría Alfredo, es una chapuza
causada por las limitaciones del lenguaje.

Pues si, el problema se podría resolver de forma más sencilla teniendo
herencia múltiple de verdad.

Por un lado, IMHO, los métodos de extensión son una chapuza que violan los
conceptos de orientación a objetos (la encapsulación). Es como si se
hubieran enfrentado a la imposibilidad de la herencia múltiple y se
decantaran por eso.

Sí que son una chapuza, pero el problema viene de que "encapsular" los
métodos dentro de las clases es un gran error. Los métodos de extensión son
un mal parche que solo soluciona una parte muy pequeña del problema y
además violan la encapsulación como dices.

La solución buena son las funciones genéricas, también llamadas
multimétodos.

Lenguajes que use la gente que tengan multimétodos de forma "nativa": creo
que ninguno :(

Lenguajes que use la gente que permiten multimétodos usando extensiones:
Java con MultiJava, Python con PEAK-Rules, Ruby, Perl, etc.

Lenguajes que no usa ni dios con multimétodos nativos: Common Lisp, Dylan,
Nice, etc.


Saludos

Hola Octavio,

El Wed, 29 Oct 2008 20:43:54 +0100, Octavio Hernandez escribió:

Para mí una de las implementaciones "ejemplares" de la herencia múltiple
(como de varias otras cosas - me vienen a la mente las aserciones,
invariantes, etc.) es la de Eiffel (que se describe en "Object Oriented
Software Construction"). Pero eso tampoco lo usa casi nadie...

No lo usa casi nadie ni habla de él casi nadie desde hace bastantes años.

Yo leí ese libro hace muchos años y no me gustó mucho. Me pareció más
marketing que ciencia. El Eiffel me pareció un lenguaje muy feo y engorroso
y muy inferior a otros lenguajes "alternativos" como Common Lisp, Dylan o
Nice. Y además el sistema de tipos de Eiffel es conocido por su falta de
solidez.

A mi cualquier lenguaje "futurista" que no tenga multimétodos no me
interesa.

Aquí explican bastante bien como los multimétodos hacen innecesario el
patrón Visitor que yo tengo que usar muy a menudo en C#:

http://nice.sourceforge.net/visitor.html


Saludos

Hola Alfredo,

On 30 okt, 15:51, Alfredo Novoa wrote:

Hola Octavio,

El Wed, 29 Oct 2008 20:43:54 +0100, Octavio Hernandez escribió:

> Para mí una de las implementaciones "ejemplares" de la herencia múltiple
> (como de varias otras cosas - me vienen a la mente las aserciones,
> invariantes, etc.) es la de Eiffel (que se describe en "Object Oriented
> Software Construction"). Pero eso tampoco lo usa casi nadie...

No lo usa casi nadie ni habla de él casi nadie desde hace bastantes años.

Yo leí ese libro hace muchos años y no me gustó mucho. Me pareció más
marketing que ciencia. El Eiffel me pareció un lenguaje muy feo y engorroso
y muy inferior a otros lenguajes "alternativos" como Common Lisp, Dylan o
Nice. Y además el sistema de tipos de Eiffel es conocido por su falta de
solidez.

Pues a mi me pareció muy bueno en aquel entonces (ya hace años).
Como también el libro de Booch, "Object oriented analysis & design
with applications". En Eiffel fue donde por primera vez ví una
implementación de conceptos que hasta entonces solo había visto
en textos académicos (por ejemplo lo de las aserciones, invariantes,
etc. que menciona Octavio).

Aunque los ŽataquesŽ de Meyer a C++ y a Stroustrup me parecían de
muy mal gusto, como tratando de darle lecciones. Creo que fué
ahí donde paré de leer con tanto entusiasmo. La impresíon que
quería dar que analizando, analizando, uno tenía que llegar de
por fuerza a Eiffel tampoco me gustaba. Eso si que tenía
mucho de folletero.

El tiempo cura todo :-) y ahora para mi está claro que me encontraba
en medio de 'la ola de moda OOP'; y muy enganchado.

Pero sigo creyendo que Eiffel es mejor que lo que estamos usando.
No mejor que lenguajes a la lisp, ni de lejos! naturalmente.

Saludos,
Carlos