Gaby, anda averiguando cuando puedas si se consigue este tipo de tamaño en pc
http://www.apple.com/es/macmini/ Saludos, Leo > -----Mensaje original----- > De: [email protected] > [mailto:[EMAIL PROTECTED] En nombre de Gabriel > Enviado el: Martes, 23 de Septiembre de 2008 15:37 > Para: [email protected] > Asunto: [clubSmalltalk] Re: Presentación de Tesis > Licenciatura - Tema: Refactoring de Traits > > Mirá, no se trata de quien tiene experiencia y quien no. > Cuando se discute se lo hace con argumentos, porque si no > gana siempre el que laburo mas años (por mas que durante esos > años se haya trabajado de muy mala manera). > En cuanto al paper ese que me pasaste, interesante, lo voy > a leer, quiza ahi existan argumentos que sostengan lo que > decis, en principio no conozco ninguno. > Por otro lado, con respecto a experiencias que contradigan lo > que decis te doy un ejemplo: Smalltalk. > Si te cabe duda leete este paper que es bastante viejito: > http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_prin > ciples_behind_smalltalk.html > Lo escribió un tal Daniel H. H. Ingalls, no se si te suena. > Saludos. > > > > El 23 de septiembre de 2008 15:07, Guillermo Schwarz > <[EMAIL PROTECTED]> escribió: > > > 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 -~----------~----~----~----~------~----~------~--~---
