Mi respeto por Bertrand Meyer termina donde él empieza a modelar las excepciones como números...Ese paper que sitas es muy viejo y luego se retractó del mismo. Por otro lado, Meyer no es muy querido en la comunidad objetos, sino averigua un poco los encontronazos que tuvo con gente en OOSPLA como Allen Wirfs-Brook, Ralph Jonhson, etc.
2008/9/23 Guillermo Schwarz <[EMAIL PROTECTED]> > 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 -~----------~----~----~----~------~----~------~--~---
