Ah, qué profundo y bien argumentado el aporte. ¿Algún ejemplo que justifique tu postura? La argumentación puede venir de conclusiones basadas en axiomas y teoremas demostrados a partir de esos axiomas mediante reglas lógicas, o bien pueden ser simplemente ejemplos que muestran que algo es verdad y que no son demostrables, como la fuerza de gravedad.
Otra cosa es simplemente abrir la boca por abrirla... 2008/9/24 Emilio Oca <[EMAIL PROTECTED]> > > No, Guillermo, simplemente estas equivocado, en general. > > Emilio > > > On 9/24/08, Guillermo Schwarz <[EMAIL PROTECTED]> wrote: > > > > 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 -~----------~----~----~----~------~----~------~--~---
