Ah, para mas detalles... http://www.youtube.com/watch?v=qnGvn-wvOkY
y http://www.youtube.com/watch?v=TqiYlnnW3_Q Andres. 2008/9/24 Andres Valloud <[EMAIL PROTECTED]>: > DOCTOR > Yo no lo podía entender de ninguna manera, querido colega, porque > usted lo pronuncia de manera incorrecta; la musa de la danza es > TerpsícoreS... > > NARRADOR > ¿Cómo puede ser "TerpsícoreS", si es una sola? A usted lo saludan > "hola, ¿cómo te va, AlbertoS?" > > DOCTOR > Mis amigos me dicen LuiS... también es uno AristóteleS, también es uno > ArquímedeS; también es uno PlatónS; albóndigaS; platóns de > albóndigas... > > > Andres. > > > 2008/9/24 Guillermo Schwarz <[EMAIL PROTECTED]>: >> Estimado Gabriel, >> >> Muchas gracias por tomarte el tiempo en contestar mi publiucación. >> >> Sí, si me suena el señoir Ingals, gracias. Aunque creo que el señor Meyer >> pesa más en la comunidad principalmente porque el mensaje es más reducido, a >> mi entender porque el señor Meyer se concentra en lo importante, mientras >> que el señor Ingals se concentra en los detalles. Ambos tipos de >> personalidades son importantes, pero si quieres aprender deberías >> concentrarte primero en lo importante, ya que los detalles los aprenderás de >> todas formas. Si por el contrario te concentras en los detalles, puede que >> descubras lo importante como puede que no. >> >> Respecto de lo que escribió el señor Ingals concuerdo en un 100% y me parece >> interesante el punto de vista, pero ¿no serán demasiados puntos a tener en >> cuenta? >> >> Lo sigo porque en vez de basarse en pocas ideas, presenta una serie de ideas >> que no son fáciles de entender por sí solas, por ejemplo: >> >> >> Leverage: When a system is well factored, great leverage is available to >> users and implementers alike. >> Take the case of sorting an ordered collection of objects. In Smalltalk, >> the user would define a message called sort in the class OrderedCollection. >> When this has been done, all forms of ordered collections in the system will >> instantly acquire this new capability through inheritance. As an aside, it >> is worth noting that the same method can alphabetize text as well as sort >> numbers, since comparison protocol is recognized by the classes which >> support both text and numbers. >> The benefits of structure for implementers are obvious. To begin with, >> there will be fewer primitives to implement. For instance, all graphics in >> Smalltalk are performed with a single primitive operation. With only one >> task to do, an implementer can bestow loving attention on every instruction, >> knowing that each small improvement in efficiency will be amplified >> throughout the system. It is natural to ask what set of primitive operations >> would be sufficient to support an entire computing system. The answer to >> this question is called a virtual machine specification: >> >> >> Ocurre que los sistemas "well factored" no pueden tener código repetido. O >> por lo menos se esperaría que tuvieran poco código repetido, sino no se >> entiende eso de "well factored". Simpáticamente ese es uno de los temas que >> más contrariedad provoca en este grupo, porque al parecer sólo entienden de >> este paper lo que les conviene o lo que no contradice sus creencias >> irracionales. Está ampliamente documentado que todas las personas funcionan >> así, en el fondo buscan corroborar sus creencias irracionales y con eso >> sicólogicamente les basta, desafortunadamente no es así como avanza la >> ciencia. >> >> El punto que estábamos dicutiendo es si corresponde crear un sistema >> partiendo como principio unificador del proyecto "modelar el mundo real". A >> este respecto el señor Ingals menciona: >> >> >> Polymorphism: A program should specify only the behavior of objects, not >> their representation. A conventional statement of this principle is that >> a program should never declare that a given object is a SmallInteger or a >> LargeInteger, but only that it responds to integer protocol. Such generic >> description is crucial to models of the real world. >> Consider an automobile traffic simulation. Many procedures in such a >> system will refer to the various vehicles involved. Suppose one wished to >> add, say, a street sweeper. Substantial amounts of computation (in the form >> of recompiling) and possible errors would be involved in making this simple >> extension if the code depended on the objects it manipulates. The message >> interface establishes an ideal framework for such an extension. Provided >> that street sweepers support the same protocol as all other vehicles, no >> changes are needed to include them in the simulation: >> >> Desafortunadamente cuando arriba dice "real world" se refiere a crear >> simulaciones del mundo real, es decir, si vas a construir una simulación, >> entonces el polimorfismo es útil. Como ustedes sabrán Smalltalk deriva en >> parte del lenguaje Simula y por ende había una espectativa de que este >> lenguaje también fuera usado para hacer simulaciones, por eso habla de mundo >> real. El señor Ingals no está diciendo que los sistemas de información deban >> construirse penando en modelar el mundo real, como al parecer alguien acá >> quiere hacernos creer. >> >> Saludos cordiales, >> >> Guillermo. >> >> 2008/9/23 Gabriel <[EMAIL PROTECTED]> >>> >>> 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_principles_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 >> >> -- >> 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 -~----------~----~----~----~------~----~------~--~---
