Hola,
Creo que una manera de entender los problemas de la HM, es entender primero
los problemas de la herencia simple. Es natural en un comienzo ver en la
herencia un mecanismo potente, pero creo que con el tiempo uno va volcándose
a componer mas y heredar menos. Si una Persona es física y jurídica a la
vez, tal vez tenga perfiles, o aspectos o características intercambiables.
En el sistema que trabajo actualmente una persona puede ser física, jurídica,
empleado, vendedor, usuario, pasajero, contacto, cliente (de distintas
categorías),
proveedor, prestador, aerolínea, etc., etc... todas estas clasificaciones
tiene aparejado comportamiento distinto. Pero eso no implica que sean
clasificaciones
"de por vida" como indica una clase, una persona va mutando, va cambiando
de características, puede ser un simple pasajer (nombre y apellido) y luego
pasar a ser un cliente con 200 atributos. Puede corresponder a una
clasificación,
a varias o a todas. Lo realmente me importa conservar en estas problemáticas
es la identidad, o sea que se trata de la misma persona. Independientemente
de su comportamiento.

La herencia, simple o multiple, también viola el encapsulamiento de los
objetos, y si además es usada en forma prematura limita la capacidad de
evolución de un ambiente. En el caso concreto de la HM ensucia el código
y agrega estructuramiento, algo que en ST por suerte existe poco.

Esta postura no quita que el problema de la dulpicación de comportamiento
en las clases exista. Es algo que se ve en Stream, por ejemplo. Hay enfoques
con traits, aspects y otros inventos... en lo personal creo que se solucionarían
si Smalltalk tuviera control del dispatching de los mensajes... pero por
desgracia eso no existe.

Diego



>
>
>Ale:
>se agradece la predisposicion, se que este tema ya se ha tratado
>mucho en la lista.
>
>>En que situaciones se te ocurre que sería conveniente
>>usarla intensivamente?
>
>(Aclaro que desconozco abundantemente el tema de la HM)
>
>Imagino que si uno se pone a usar HM para todo lo que se pueda,
>aparecerían menos frameworks (para mi siempre han sido dificiles de
>entender, se me olvidan a las dos semanas, no pego una cuando quiero
>modificar un framework hecho por otro) y tal vez una forma de
>programar distinta a la habitual, mas modular, esto es imaginación
>muy trasnochada, nada concreto, unos ejemplos:
>
>- La separación entre modelo y vista podría simplificarse haciendo
>que un objeto heredara de miModelo y una vista, mantenemos la
>separación y la vinculación queda explícita y clara, uno sabe en
>donde esta el comportamiento que quiere modificar a primera vista.
>
>- Un cliente que puede ser persona física o jurídica, se podrían
>crear las tres clases y que cliente herede de una persona u otra,
>esto modulariza los conceptos y por ello es mas sencillo de comprender
>
>- Tengo un cliente, un provedor, los dos pueden ser personas físicas
>o personas jurídicas, con HM modelaría estas 4 clases, con HSimple
>tendría que armar un framework que, en principio, parece mas
>complicado
>
>Un saludo grande!
>Diego
>
>
>
>
>
>
>
>
>
>Para más información sobre la Asociación escribir a info@...
>
>Smalltalking es un espacio colaborativo creado para el estudio y desarrollo
>en Ambientes de Objetos.
>Se sustenta gracias a la participación de sus socios.
>
>Las reglas de etiqueta sobre la lista están en
http://www.smalltalking.net/join/netiquete.htm
>
>Enlaces de Yahoo! Grupos
>
>
>
>
>
>