Quería comentar un detalle: Los "accessors" no resuelven el problema de la encapsulaciòn y la herencia. La herencia rompe la encapsulaciòn porque las clases derivadas se rompen cuando una clase base es modificada (si se cambian sus variables de instancia por ejemplo). Accesors màs o accesors menos, las clases derivadas dejan de funcionar de todas maneras, por eso son tan importantes las pruebas unitarias.
Lo que pasa es que, si utilizamos bien el concepto de subclasificación, todas las superclases deberían ser abstractas (por lo menos la incluidas por nosotros para modelar nuestro sistemas, porque ya sabemos que las clases de Smalltalk no cumplen con esto). Así, toda superclase, al ser abstracta, no debería tener colaboradores internos (variables de instancia). Si no utilizamos esta premisa a la hora de modelar, creo que en lugar de estar buscando un buen modelo, estamos considerando solo cuestiones implementativas. Y en este caso por ahí ya no tiene tanto sentido fijarse si se rompe o no el encapsulamiento, porque habría cosas más importantes para mejorar antes que eso. Es solo una opinión. ¿Qué piensan ustedes? 2008/9/11 Guillermo Schwarz <[EMAIL PROTECTED]> > Buen punto, el mismo que hizo Alan Kay, que debiò haberse llamado Message > Oriented programming en vez de Object Oriented. > > Pero creo que de todas maneras el problema no se resuelve ahí. El paradigma > de enviar mensajes es tan simple como usar XML o usar web services. Pero eso > al final no significa nada hasta que los mensajes no se vuelven > polimòrficos, de modo que volvemos a lo mismo: El polimorfismo y que el > còdigo no esté repetido. > Los "accessors" no resuelven el problema de la encapsulaciòn y la > herencia. La herencia rompe la encapsulaciòn porque las clases derivadas se > rompen cuando una clase base es modificada (si se cambian sus variables de > instancia por ejemplo). Accesors màs o accesors menos, las clases derivadas > dejan de funcionar de todas maneras, por eso son tan importantes las pruebas > unitarias. > > Saludos, > Guillermo. > 2008/9/11 Andres Valloud <[EMAIL PROTECTED]> > >> >> Me parece rarisimo que se hable de enseñar objetos y no se mencione la >> palabra mensaje ni una vez. Ademas, me parece que al polimorfismo le >> falta algo... no me parece que sea solo herencia + encapsulacion. >> Finalmente, lo que a mi gusto rompe la encapsulacion con herencia es >> codigo mal escrito. Si uno usa accessors no hay (creo) problemas. >> >> Andres. >> >> 2008/9/11 Guillermo Schwarz <[EMAIL PROTECTED]>: >> > Estoy 100% de acuerdo contigo aunque puede que no estés 100% de acuerdo >> > conmigo... ;-) >> > >> > Supongo que el problema es la manera en que se enseña orientación a >> objetos: >> > >> > OO = Herencia + Encapsulación + Polimorfismo >> > >> > Polimorfismo = Herencia + Encapsulación >> > >> > => OO = 2 * Polimorfismo >> > >> > Luego se enteran que: >> > >> > Herencia => ! Encapsulación >> > Y colapsan. >> > >> > Lo que yo haría diferente es explicar a los nuevos estudiantes de OO lo >> > siguiente: >> > >> > 1. El punto está en que lo que se quiere lograr es el polimorfismo y el >> > mecanismo para lograr eso podría ser herencia + encapsulación. >> > 2. Como herencia => ! encapsulación, miremos una alternativa que son los >> > proxies. ¿Cómo podemos hacer todo con proxies en vez de herencia? >> > >> > Entonces la idea de los traits parece una buena idea. Si se usa un >> > compilador o no ya es otro cuento. >> > >> >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> >> >> --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] http://www.clubSmalltalk.org -~----------~----~----~----~------~----~------~--~---
