Re: Otra vez la herencia múltiple

[Beni]

Muchas gracias a todos, se me han aclarado conceptos y he aprendido otros.

Me quedo, resumiendo:

- Si es posible, evitar la herencia multiple, usando tipos (interfaces) para
definir otra funcionalidad o protocolos de comunicación que debe tener la
clase hija.
- Si tenemos class A (B,C,D), A hereda de B e implementa los tipos C y D, o
le añaden funcionalidad a traves de los mixins C y D.

Supongo que se me olvidará algo... pero lo importante son las ideas
generales.

La verdad, viendo como otros lenguajes como Delphi, el Java, el C# (que
comenta Medardo) donde se pueden definir a nivel de lenguaje programación
varios conceptos, me da penilla ver que python no tiene esa potencia y tener
que recurrir a construcciones para implementarlas.

Por cierto Medardo eres un crack, a ver si tienes suerte con Shakira :P

Saludos.

2008/7/28 Medardo Rodriguez <med.swl en gmail.com>

> 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
>



-- 
Benito Rodríguez Arcos
------------ próxima parte ------------
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes