JA JA JA Qué buen chiste.
Como todos los anteriores que pusieron... 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 > > > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
