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