Guillermo, sinceramente esta discusion me parece que termina como la otra.. ya fue. Ahora me gustaría encausarla hacia un rumbo mas fructifero. Me gustaría que nos cuentes que consideras un buen diseño de software. Es decir, que tiene que tener tu programa para estar bien hecho. Y me gustaría saber en que ayuda la programación con objetos a lo que vos propones.
El 24 de septiembre de 2008 18:56, Guillermo Schwarz < [EMAIL PROTECTED]> escribió: > Claro, yo equivocado y Alan Kay también... > > The Origins of Object Orientation Source: > comp.object.moderated<news:comp.object.moderated> > Date: 08-Feb-2000 > > Related Sites <http://ootips.org/history.html#links> > > > [image: ------------------------------] > [image: o-<] *Problem*: Was object oriented programming invented so that > it would be possible to write programs that model the real world? > > > [image: ---------------] > [image: o-<] Patrick Logan <[EMAIL PROTECTED]> wrote: > > This is a widely held misconception. If you read the history of Smalltalk > by Alan Kay you will find that he coined the term "object oriented > programming" by applying it to his language, Smalltalk, in the early 1970s. > > Alan Kay, in his history in the ACM HOPL II proceedings, explains what he > means by object-oriented programming. He does base it on the concept of a > cell that has a wall. Information passes through the cell wall, but what is > on the inside is hidden from what is on the outside. That is the extent of > his metaphor. > > In the 1960s he observed several software systems that had "cell-like" > behavior in the sense that they had encapsulated data and data-independent > information moving through the boundary of the encapsulation. These systems > he observed included the Sketchpad graphics system, the Simula simulation > system, and a Burroughs operating system. > > Contrary to popular belief, Simula was not the first object-oriented > programming language, and it was not intended to model "the way the world > really works". Although as I wrote, it did influence the first OOPL. It was > intended to be a simulation programming language. The developers evolved an > encapsulation/message like mechanism because it helped them write complex > simulations, not because it helped them imitate. They subsequently found > that Simula served as a good general purpose programming language because > all programs benefit from managing complexity. > > Alan Kay did not call OO a model of the real world. Historically, that > aspect of OOP came later. Examining the ancient manuscripts will reveal the > chronology as opposed to the doctrine. > Taken from: http://ootips.org/history.html > > ¡Qué lástima por ustedes, pero alguien les tenía que enseñar! Los remedios > son amargos, pero hacen bien. > Ah, y por cierto, no me lo agradezcan, lo hago por su bien. > > Saludos, > Guillermo. > 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<http://users.ipa.net/%7Edwighth/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 >> > >> > > >> > >> > >> > >> >> >> 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 -~----------~----~----~----~------~----~------~--~---
