Re: Otra vez la herencia múltiple

[Medardo Rodriguez]

2008/7/25 Beni <camontuyu en yahoo.es>:
> Unas preguntillas, si me lo permitis.

Claro, esto es para preguntar y responder.

> - Tenía entendido que la composición, en la POO, es cuando un objeto está
> compuesto de otros, por ejemplo un Linea está compuesta de dos Puntos
> (origen y final). Se modeliza mediante referencias no con herencia.

Ya te respondieron un poco, yo complemento.
Hablas de composición entre objetos, pero las relaciones de
composición se pueden expresar en más de un contexto. Creo que la
programación no se debe ver basada en «recetas» o «patrones», aunque
éstos ayudan mucho ingenierilmente.
Las relaciones entre las clases y los mixins son de composición
también. Muchos de los problemas que tienen los lenguajes
tradicionales es que se ha intentado usar la herencia para todo:
* se ha tratado de estructurar clases con ella (composición), lo cual
es incorrecto. A finales de los 80s (creo) el Borland Pascal sacó un
mal ejemplo y por la fuerza que tenía ese lenguaje en aquella época,
hizo mucho daño. Se heredaba del punto como figura geométrica para
formar clase de la línea, el círculo, el rectángulo, etc.
* Usar tipos cómo métodos definidos en las clases. Es un disparate
conceptual que en una clase hayan métodos no implementados, pero la
carencia de estructuras formales para definir tipos (interfaces)
autónomos, ha obligado a esto.

Hay tecnologías que en vez de tener herencia han usado la composición
entre clases para reutilizar comportamiento. Por ejemplo COM+ de
Microsoft ( y pido disculpas por mencionar algo que no es Software
Libre ahora mismo).

> - No sabía lo que erran los mixmis y he estado leyendo sobre los mixis en la
> wikipedia. Parecen interesantes.

Bueno, es un concepto simple. Puedes tener comportamiento aprovechable
en clases que conceptualmente son disjuntas (no heredan unas de otras
de ninguna forma). Entonces un mixin no se puede usar por sí solo,
está orientado a posibilitar aprovecharlos en muchos lugares sin
repetirse.

> - Cuando te refieres a interfaces (tipos), ¿qué es exactamente? ¿lo típicos
> interfaces como los de java que obligan a definir una serie de
> funcionalidad?


Un tipo es un protocolo de comunicación que establece la semántica de
la relación entre dos objetos. Te pongo un ejemplo clásico:
Tienes la clase Mujer y la clase Hombre.
hay dos instancias de Hombre (med y beni) y una de Mujer (shakira).

shakira es amante de med :)
shakira es hermana de beni.

Esto establece dos relaciones, donde el objeto origen es de la clase
Mujer y el de destino siempre es de la clase Hombre. Sin embargo, las
operaciones (métodos) que se le pueden aplicar a un Hombre estarían
mal si se dejan a nivel de la clase, porque si shakira le hace a beni,
que es su hermano, lo que me hace a mi (en sueños, claro) por ser mi
amante, se estaría cometiendo tremendas tropelías.
La programación debe representar modelos como se entiendan de la
realidad. Por tanto, declarar los protocolos de comunicación entre
objetos, como se hace tradicionalmente, en las clases es incorrecto,
pero eso ha sido casi lo que hemos visto por la mala calidad de los
lenguajes de programación.
Estos protocolos deben definirse independientemente y las clases no
deberían tener interfaces públicas, sólo deberían implementar estos
tipos.
El Delphi, el Java, el C#, etc. son lenguajes que permiten la
definición de tipos formales independientes.

En Python, a pesar de que es un lenguaje dinámico,  están emergiendo
tecnologías (como Zope3) que permiten trabajar con el concepto de
interfaces.

Los invito, a los que estudien programación desde el punto de vista
científico, a estudiarse un axioma genial que le da fundamento a toda
la teoría de tipos:
Liskov substitution principle
http://en.wikipedia.org/wiki/Liskov_substitution_principle

Éste es un tema muy amplio, y me cuesta trabajo resumir para este espacio.

Saludos
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes