En mi pobre experiencia (comparada por supuesto con tu vasta experiencia en el tema ;-), la recomendaciòn de "modelar la realidad" rara vez funciona, y cuando funciona, lo hace por un periodo tan breve y en forma tan corrupta, que es mejor no seguir esa recomendaciòn.
Hay otros que tienen la misma visiòn: http://www.developertutorials.com/tutorials/php/what-is-object-oriented-programming-070130/page2.html "Reasoning too much in terms of the real world can actually be detrimental to software quality" http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel1/2/11070/00511974.pdf?arnumber=511974 Y lo dice un señor llamado Bertrand Meyer... no sé si les suena... Si tienen experiencias que contradigan lo que digo o al señor Meyer serìa bueno que las compartieran para que todos aprendamos de su infita sabidurìa... Saludos cordiales, Guillermo. 2008/9/22 Gabriel <[EMAIL PROTECTED]> > Es increible que no puedas entender que modelar la realidad no significa > modelarla entera. Obviamente que siempre es un modelo simplificado, la > realidad es infinita, ni siquiera creo que exista la posibilidad de hacer un > modelo completo de toda la realidad. > Pero a ver si entendes, podes modelar algo y tratar de no perder de vista > el gap semantico y no por eso eso que modelaste modele la realidad entera! > lo importante es que siempre que sea posible te acerques lo mas que puedas. > Si queres no repetir codigo podes hacerlo con programación procedural y no > se para que complicas todo con objetos y mensajes, en el lugar que va el > mismo codigo llama a la misma funcion y listo. > > El 22 de septiembre de 2008 1:47, Guillermo Schwarz < > [EMAIL PROTECTED]> escribió: > > >> >> 2008/9/18 Abel Armoa <[EMAIL PROTECTED]> >> >>> Guillermo, hay algo que no entiendo cuando decís: >>> >>> Proxy: Clase que permite agregar comportamiento a otras clases sin usar >>>> herencia, sino usando composiciòn, de modo que la clase X preexistente >>>> adquiere el comportamiento del Proxy P cuando esta clase se encuentra >>>> envuelta en el proxy P. >>>> >>> >>> ¿Cómo puede ser que una clase preexistente adquiera nuevo comportamiento >>> mediante el Proxy? >>> >> >> a := Object new. >> a := PersistentProxy for: a. >> >> la idea es que PersistentProxy es una clase que al mandarle el mensaje >> for: crea una nueva instancia de sì misma que intercepta todos los mensajes. >> >> >>> La únca forma que se me ocurre que pueda pasar esto es que un proxy se >>> maneje a nivel meta y redefina o agregue comportamiento a la clase. Pero sé >>> que los Proxy no hacen esto (o por lo menos no es su objetivo inicial). >>> >> >> Si. >> >> >>> Otra duda que me surge es cómo hacés para envolver una clase con un >>> Proxy. Porque la implementación de Proxy que yo conozco es la de un objeto >>> que tiene como colaborador interno a otro objeto. El proxy recibe los >>> mensajes de otros objetos y decide en cada caso si delega algo en su >>> colaborador o no, si hace algo antes de delegar o después, etc. >>> >> >> Sí. en Smalltalk si recuerdo bien, se redefine el mètodo >> doesNotUnderstand. En Java se utliza un mecanismo llamado Dynamic Proxy que >> involucra al compilador. Me da la impresiòn que es màs sofisticado el >> mecanismo en Smalltalk porque permite redefinir mètodos, mientras que en >> Smalltalk sòlo funciona si llegas al mètodo "doesNotUnderstand". >> >>> >>> ¿A qué te referís cuando decís que le agregás comportamiento a la clase? >>> >> >> desde el punto de vista del usuario del objeto, el objeto ha adquirido >> comportamiento que antes no tenìa. >> >>> >>> Y después cuando decís: >>> >>> Trait: Clase que permite agregar comportamiento a otras clases sin usar >>>> herencia, sino usando composiciòn, de modo que las clase X es creada como >>>> un >>>> trait T del cual se extiende y se redefninen algunos de sus mètodos. >>>> >>> >>> No entiendo a qué te referís con composición de clases. ¿Podrías explicar >>> un poco esto? >>> >> >> La idea es que las cuando estàs creando tus clases, puedes usar "is a" o >> "has a", por ejemplo, un una manzana "is a" fruta, un auto "has a" motor, >> etc. >> >> Cuando utilizas "has a" estàs pensando en composiciòn mientras que cuando >> estàs usando "is a" estàs usando herencia. >> >>> >>> Menos còdigo => menos costo >>>> >>> >>> Para mi en realidad la cantidad de código no es importante, sino cuán >>> bien modelado está el problema a tratar. Qué tanto se acerca mi modelo a la >>> realidad. Y ahí sí, cuanto más se acerca => menos costo (pero no creo que >>> influya directamente en el costo, sino porque el modelo va a ser más fácil >>> de entender, mantener, reutilizar, extender, etc.) >>> >> >> Desafortunadamente la orientaciòn a objetos no tiene nada que ver con la >> realidad, para eso estàn los casos de uso, es decir, el modelamiento de las >> funcionalidades basadas en los "casos" en que el sistema serà usado. Una vez >> que eso està modelado, los objetos son simplemente mecanismos de >> implementaciòn. >> >> Los objetos del dominio (del problema) no deben ser màs del 10% de los >> objetos del sistema y hasta donde he podido ver nunca estàn listos, nunca >> representan adecuadamente la "realidad", sino màs bien satisfacen los >> requerimientos en el mejor de los casos y punto. >> >> Un tìpico ejemplo son las direcciones. Por ejemplo los clientes tienen >> direcciòn. La direcciòn tiene calle, nùmero, telèfono, comuna, ciudad y >> paìs. El cliente puede tener ademàs un telèfono celular. El telèfono normal >> puede tener ademàs una direcciòn y un contacto, donde el cantacto es una >> persona que trabaja en esa direcciòn y que tìpicamente tiene un cargo. Y >> todo eso sòlo para representar la direcciòn de un cliente. >> >> Luego un cliente sale con el pastelito de que tiene màs de una direcciòn, >> una direcciòn con màs de un telèfono, un telèfono con màs de un contacto, un >> contacto con màs de un cargo. >> >> Es muy difìcil de implementar para ser un problema tan simple, pero >> principalmente porque "modelar la realidad" no deberìa ser el objetivo. >> >>> >>> Saludos, >>> Abel Armoa >>> >>> >>> -- >>> Saludos cordiales, >>> >>> Guillermo Schwarz >>> Sun Certified Enterprise Architect >>> >> >> >> > > > > -- Saludos cordiales, 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 -~----------~----~----~----~------~----~------~--~---
