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 -~----------~----~----~----~------~----~------~--~---
