Gabriel, Recojo el guante, siempre es interesante discutir estos temas, a pesar de que ya fueron ampliamente discutidos hace años, me parece que nunca he leído esto en Castellano, así que acá va:
ok, si "reducir el código repetido" y "crear un modelo coherente de la realidad" son conceptos diferentes, ¿cuál es la diferencia? ¿Cómo decides en un caso que se debería haber hecho A en vez de B y viceversa? Te lo pregunto porque si no hay un discriminante, entonces es una diferencia superflua o sólo aparente. Es como los sistemas de referencia en física, en un sistema de referencia el objeto está quieto, mientras que en otro se está moviendo con velocidad constante. No importa cual se seleccione, las conclusiones que se pueden obtener de ambos son las mismas y no se contradicen en nada. Y esto es más relevante de lo que crees, porque al menos en un contexto en particular, el desarrollo de software, no parece haber diferencia, lo que es sorprendente y puede dar luces respecto de lo que realmente estamos haciendo cuando programamos. Hay proponentes de la orientación a objetos que plantean que programar es lo mismo que crear una teoría. Cambias un axioma y la teoría se derrumba, o el espacio deja de contener materia. Me parece muy relevante y contenporàneo ahora que van a echar a andar el LHC ;-D Respecto de "El objetivo de programar con objetos es hacer buenos modelos" Creo que esto cae en la trampa de "los objetos representan el mundo tal como es y el objetivo de programar con objetos es representar la realidad". En realidad es todo lo contrario, los proyectos que han sido dirigidos siguiendo ese punto de vista siempre terminan fracasando porque no tienen un discriminante que les permita determinar cuando están herrando el rumbo. Por ejemplo, sería muy interesante modelar los atributos de una manzana y sus comportamientos, pero si estamos haciendo un software contable para pymes que exportan manzanas, probablemente basta con una clasificación general de las manzanas siguiendo los atributos de valor que ve el cliente, en vez de "tratar de modelar al realidad" (llamémosle la "trampa de la realidad" ya que no conozco un nombre mejor). En particular muchos objetivistas (¿cómo se les llama a los proponentes de la orientación a objetos?) consideran que eso de modelar la realidad es una falacia, y proponen que es mucho más razonable modelar interacciones con el usuario (casos de uso) que tratar de modelar "objetos". Incluso XP sigue esta mima idea con sus user stories que no son otra cosa que caso de uso sin formato. De hecho el mismo Alan Kay, el que inventó el témino "orientación a objetos" señala que si pudiera le cambiaría el nombre a "orientado a mensajes" ya que ese término captura más adecuadamente el objetivo de su propuesta. "Actually I made up the term object-oriented and I can tell you I did not have C++ in mind. The important thing here is that I have many of the same feelings about Smalltalk." —Alan Kay Tomado de: http://weblog.raganwald.com/2007/10/too-much-of-good-thing-not-all.html "At PARC we had a slogan: "*Point of view is worth 80 IQ points*." It was based on a few things from the past like how smart you had to be in Roman times to multiply two numbers together; only geniuses did it. We haven't gotten any smarter, we've just changed our representation system. We think better generally by inventing better representations; that's something that we as computer scientists recognize as one of the main things that we try to do." —Alan Kay Tomado de: http://www.ecotopia.com/webpress/futures.htm "I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)." —Alan Kay salu2, Guillermo. 2008/5/7 Gabriel <[EMAIL PROTECTED]>: > Es cierto lo que decis, pero hay algo esencial que no comparto, lo > importante no es REDUCIR CODIGO, lo importante es tener un modelo lo mas > sencillo posible para entender, comunicar, modificar, etc. Ahi debe estar > enfocado el problema. Naturalmente un codigo fuente que que tiene partes > repetidas no pareceria ser un buen modelo. Por esto es que el hecho de no > repetir codigo es una CONSECUENCIA de tener un buen modelo. > El objetivo de programar con objetos es hacer buenos modelos. > Si el objetivo de reducir codigo fuera tan importante entonces podriamos > tener variables con nombres como: i, j, a, b, c, etc. lo mismo con los > nombres de mensajes. > Pero todos sabemos que ese no seria un buen modelo, porque seria > dificultoso de comunicar, entender, modificar. Y seria dificil tambien ver > como en ese modelo se refleja el dominio que estamos modelando. > > Igualmente es una opinion, no se que opinan los demas. > Saludos. > Gabriel > > 2008/5/7 Guillermo Schwarz <[EMAIL PROTECTED]>: > > Hola Abel, > > > > Me perdì con tanta respuesta a este thread y revisàndolo me di cuenta > > que tenìa unas respuestas pendientes. > > > > Esto de los objetos biològicos se debe a que el inventor de Smalltalk, > > Alan Kay, estudiò biología molecular y por eso según él tiene este "bias" de > > mirar el mundo como un sistema de objetos independientes que se comunican a > > través de mensajes químicos, entonces viendo el trabajo que habían hecho en > > Simula le sirvió de inspiración para crear un lenguaje en el que no > > existiera otro mecanismo que objetos y mensajes entre ellos. > > > > Acà está su biografía para los que quieran corroborar lo que he escrito: > > http://ei.cs.vt.edu/~history/GASCH.KAY.HTML > > > > Eso de reducir el código repetido en realidad es algo fundamental, mucho > > más fundamental que la orientación a objetos, primero porque la precede en > > el forma de la creación de subrutinas en FORTRAN, y además porque otros > > mecanismos más avanzados como AOP y Traits, que escapan de las "cadenas" de > > las jerarquías de clases, también siguen el mismo principio de eliminar el > > código repetido. > > > > Si haces un análisis del código repetido de un proyecto cualquiera verás > > que entre el 10% y el 70% del código es código repetido. Si lo pudiéramos > > eliminar los proyectos serían mucho más económicamente rentables y además el > > costo de mantención disminuiría, sin mencionar que además la calidad del > > código fuente subiría sólo por el hecho de que habría menos defectos, y > > sería más fácil solucionarlos. > > > > Respecto de crear prototipos, esa es la tìpica solución para guardar > > "estado" en la clase factory, donde el factory es realmente un objeto del > > mismo tipo que simplemente se clona. Es interesante para ambientes gráficos > > en los que quieres que el usuario sea capaz de crear sus propios tipos de > > objetos (algo así como un GUI painter en el que el usuario pueda definir sus > > nuevos elementos gráficos, Smalltalk Express tenía algo así, y escrito en > > muy pocas líneas de código). De esto estamos hablando que era del año 1996, > > estamos en el 2008, 12 años después, y aún no veo nada parecido en Java > > (bueno excepto un framework que estoy desarrollando parecido a Seaside pero > > en Java). > > > > Tmabièn existen lenguajes prototìpicos en los que no existe la herencia > > sino que el ùnico mecanismo para crear nuevos objetos es sacar una copia de > > los anteriores, irlos modificando (agregando mètodos por ejemplo) y leugo > > volver a sacar copia. Me parece que Smalltalk està pintado para hacer eso. > > > > Respecto de la pregunta que hace gallego, no he tenido la suerte de > > trabajar sólo con traits. En general lo que me detiene es que se tenga que > > crear un lenguaje especial para trabajar con traits, prefiero usar una > > biblioteca, pero no sólo eso, además se debe encontrar un problema en el que > > no baste con Proxy sino que además sea necesario usar Traits, pero > > desafortunadamente los proyectos en los que he participado son demasiado > > fáciles. Eso es bueno y es malo. Es malo porque no hay proyectos lo > > suficientemente desafiantes como para aprender nuevas tecnologìas (a menos > > que SOA y activemq sean considerados "nuevos", a mi parecer no son más que > > los mismos viejos lobos con disfraz de nuevas ovejas), pero por otro lado me > > parece que es bueno porque significa que si aprendes Traits tendràs una > > oportunidad de hacefr negocio en las tecnologías que se vienen. > > > > Uno de los temas que me parece interesante es la integración de las > > tecnologías de bases de datos relacionales y la orientación a objetos. En > > particular hay papers y publicaciones en general de Codd y Date que critican > > duramente a SQL, que como lenguaje deja mucho que desear. Me parece que esa > > crítica está revelando una oportunidad. > > > > Por otro lado la integración de tecnologías de orientación a objetos con > > SQL da entre risa y pena, pretende resolver que los programadores escriban > > tanto SQL (como Hibernate por ejemplo), pero la integración es > > increíblemente pobre. Me da la impresiòn que ambos problemas estàn > > relacionados y que se podrìa construir un modelo mucho más coherente y > > eficiente (tengo rudimentos ya implementados), de modo que no haya que darse > > tantas vueltas para implementar el modelo de base de datos y realizar los > > mappings. de hecho, creo que lo importante es tener claridad respecto de què > > se està modelando, el resto debiera deducirse automàticamente, hasta las > > pantallas deberìan deducirse autmàticamente a partir del modelo, y no > > deberìa ser necesario utilizar generadores de còdigo, sino que tener una > > biblioteca pequeña de unos 10 KLOC y una descripciòn del sistema de unas 500 > > LOC y todo el resto deberìan ser datos. > > > > Hasta donde he podido llegar el sistema es increíblemente eficiente y > > fácil de implementar. El único problema es que necesito gente que le > > interese y que tenga tiempo disponible. > > > > Bueno aparte de eso, hacerlo en Smalltalk me parece riesgoso, ya que > > depende del vendor si tu producto corre o no, mientras que en Java lo he > > probado en todos los app servers a los que he tenido acceso y corre > > igualito. Creo que eso es importante. Migrarlo a Smaltalk luego sería fácil, > > pero al revés no me parece que sea cierto. > > > > Mi inspiración en esto es la biblioteca curses en C++. Esa biblioteca > > podái manejar cientos de terminales difrentes de manera muy eficiente. > > Cuando empezamos a tener problemas de desemepeño se nos ocurrió reimplementr > > curses. Al principio tuvimos mucho éxito, pero luego en la medida que > > nuestra biblioteca fue creciendo, curses nos empezó a ganar. ¡Sorpresa! > > > > La razón es que curses era de alto nivel, de modo que aunque ciertas > > operaciones no eran lo más eficientemente posible, aún así, las > > optimizaciones de alto nivel que tenía la hacían más eficiente en una > > aplicación con suficiente operaciones a nivel de pantalla, al mismo tiempo > > que estaba garantizado que podría manejar montones de pantallas diferentes, > > incluso nuevas si salían a pesar que ya no salían y casi todas las que > > habían se habían estandarizado en 2: ansi y vt100. > > > > Pues bien, el resultado es que nos dimos cuenta que curses era una capa > > de abstracción respecto de los temrinales que terminaba siendo más > > eficiente. Es es contra intuitivo, pero los hechos son más importantes que > > las intuiciones. Y empezamos a mirar más nuestras bibliotecas como capas de > > abstracción y negándonos a dejar que se transparentara la implementación. El > > resultado fue que pudimos colocar optimizaciones que de otra manera no > > hubiéramos podido. > > > > Y raya para la suma, las capas de abstracción se podían poner una sobre > > otra haciendo que el sistema fuera mucho más eficiente de lo que hibiera > > sido si hubiéramos dejado que se transparentara la implementación, sin > > ademàs mencionar que necesariamente tenáimos menos defectos porque al crear > > la capa de abstracción estábamos efectivamente logrando que en caso de que > > el diseño interno tuviera defectos se puediera cambiar sin afectar a los > > usuarios de la biblioteca, el resultado fue mejor por lo tanto no sólo desde > > el punto de vista del desemepeño, sino además desde el punto de vista de la > > calidad. > > > > saludos, > > Guillermo. > > > > 2008/4/25 Abel Armoa <[EMAIL PROTECTED]>: > > > > > Hola Guillermo: > > > No entendí qué querés decir con "creación de objetos biológicos". ¿Qué > > > son los objetos biológicos? > > > En cuanto a que la idea de la orientación a objetos como reducción de > > > código repetido a través de jerarquías de clases, no estoy de acuerdo. Me > > > parece que el hecho de evitar la repetición de código es mejor verlo como > > > una consecuencia, y no como parte del corazón de la orientación a objetos. > > > Por otra parte, hacés referencia a jerarquías de clases, sin embargo creo > > > que es posible trabajar con objetos en ambientes de prototipación, donde > > > no > > > tendrías las jerarquías de clases en primera instancia. En este caso, > > > según > > > la segunda definición, no estaríamos hablando de orientación a objetos, > > > cuando en realidad sí entran dentro de la categoría. > > > > > > Saludos, > > > Abel Armoa > > > > > > 2008/4/25 Guillermo Schwarz <[EMAIL PROTECTED]>: > > > > > > La idea de la orientaciòn a objetos se puede ver como la creaciòn de > > > > objetos biológicos (de ahí su nombre, no muy apropiado por cierto, por > > > > parte > > > > de Alan Kay que fue el inventor del término y que estudió biología > > > > molecular), pero además se puede ver como la reducción del código > > > > repetido a > > > > través de las jerarquías de clases. > > > > > > > > Acà hay un ejemplo de Traits y cómo se puede eliminar la repetición > > > > de las colecciones en Smalltalk: > > > > http://portal.acm.org/citation.cfm?doid=949305.949311 > > > > > > > > "La" explicación de Traits: > > > > http://www.iam.unibe.ch/~scg/Archive/Papers/Scha03aTraits.pdf en > > > > Smalltalk. > > > > > > > > Saludos, > > > > Guillermo. > > > > > > > > 2008/4/23 Jose Gregoris <[EMAIL PROTECTED]>: > > > > > > > > Hola gente. > > > > > > > > > > Perdon que me meta en la charla, pero no entendí esto: > > > > > > > > > > * He leìdo de proyectos que estàn tratando de programar todo con > > > > > Traits (muy parecido a los Mixins), pero en vez de usar herencia para > > > > > resolver los comportamientos similares, encadenan Traits. Al parecer > > > > > la > > > > > desilusiòn de las jerarquìas de clases nos ha llevado a esto, lo que > > > > > hace > > > > > que los lenguajes sean cada vez màs dinámicos, ya que en tiempode > > > > > ejecución > > > > > se podría agregar un trait a un objeto sin necesidad de instanciarlo > > > > > de > > > > > nuevo > > > > > *,* mientras que con las jerarquìas de clases hay que recompilarlo > > > > > todo. > > > > > * > > > > > Sobre todo lo de recompilar todo, se refieren a ST o ( JAVA C#) > > > > > Saludos kiko > > > > > > > > > > > > > > > *Guillermo Schwarz <[EMAIL PROTECTED]>* escribió: > > > > > > > > > > El mayor problema que tienen tanto Java como C# es que tienen > > > > > early binding en vez de late binding, es decir, se trata de resolver > > > > > todo en > > > > > tiempo de compilaciòn, de modo que el truco del #doesNotUnderstand no > > > > > es > > > > > practicable ni en Java ni en C# (ok, todos sabemos que sì tienen late > > > > > binding, pero es menos late que en el caso de Smalltalk). > > > > > > > > > > Sin embargo en Java desde la versiòn 1.3 existen los dynamic > > > > > proxies que vienen a hacer lo mismo pero con tipos estàticos. Ahora > > > > > bien, la > > > > > cantidad de lìneas de còdigo para hacer lo mismo bordea las 70 lìneas > > > > > de > > > > > código dependiendo de còmo se cuente, es decir unas 10 veces màs. Sin > > > > > embargo considero que eso no es lo impresionante si despuès de todo > > > > > eso se > > > > > meterà dentro de una biblioteca, de modo que da lo mismo la cantidad > > > > > de > > > > > lìneas de còdigo, lo impresionante es el còdigo resultante con que > > > > > queda la > > > > > aplicaciòn, que al tener proxies dinàmicos permite asociaciones en > > > > > tiempo de > > > > > ejecuciòn. > > > > > > > > > > El truco surgiò inicialmente en Smalltalk como el patròn de diseño > > > > > llamado Proxy. Luego se concirtiò en Mixins para simular herencia > > > > > múltiple. > > > > > Luego se convirtió en AOP que finalmente es lo mismo. > > > > > > > > > > He leìdo de proyectos que estàn tratando de programar todo con > > > > > Traits (muy parecido a los Mixins), pero en vez de usar herencia para > > > > > resolver los comportamientos similares, encadenan Traits. Al parecer > > > > > la > > > > > desilusiòn de las jerarquìas de clases nos ha llevado a esto, lo que > > > > > hace > > > > > que los lenguajes sean cada vez màs dinámicos, ya que en tiempode > > > > > ejecución > > > > > se podría agregar un trait a un objeto sin necesidad de instanciarlo > > > > > de > > > > > nuevo, mientras que con las jerarquìas de clases hay que recompilarlo > > > > > todo. > > > > > > > > > > Saludos, > > > > > Guillermo. > > > > > > > > > > 2008/4/21 GallegO <[EMAIL PROTECTED]>: > > > > > > > > > > > > > > > > > Hola Bruno: > > > > > > > > > > > > Bruno Buzzi Brassesco escribió: > > > > > > > > > > > > > > Discutiendo con un amigo que decía que Smalltalk no tenia > > > > > > herencia > > > > > > > múltiple. > > > > > > > > > > > > > > Aunque sea discutible la necesidad de herencia múltiple, me > > > > > > pregunte > > > > > > > cuan rápido se podrá implementar herencia múltiple en > > > > > > Smalltalk y > > > > > > > poner a prueba su flexibilidad. > > > > > > > > > > > > > > En "7 líneas de código" o 5 minutos ... hice esto: > > > > > > > > > > > > > > Se puede discutir sobre la validez de la implementación (la > > > > > > variable # > > > > > > > superinstances y sus implicaciones) pero NO es el punto > > > > > > central. > > > > > > > > > > > > > > Lo central es que si en 5 minutos se puede hacer esto, que > > > > > > será > > > > > > > después de estar un año trabajando sobre un tema... > > > > > > > > > > > > > > Implementa algo así en C# (u otro) valor!!! > > > > > > > > > > > > > Muy bueno! > > > > > > Se llega a resultados sorprendentes. Lo que no entiendo es > > > > > > porque en C# > > > > > > no se podría hacer lo mismo. Me gustaría que me explicaras los > > > > > > motivos > > > > > > (por los cuales no se puede) ya que eso que mostraste es muy > > > > > > simple. > > > > > > > > > > > > Saludos > > > > > > GallegO > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Saludos cordiales, > > > > > > > > > > Guillermo Schwarz > > > > > Sun Certified Enterprise Architect > > > > > ------------------------------ > > > > > > > > > > Yahoo! Encuentros > > > > > Ahora encontrar pareja es mucho más fácil, probá el nuevo Yahoo! > > > > > Encuentros. > > > > > Visitá http://yahoo.cupidovirtual.com/servlet/NewRegistration > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Saludos cordiales, > > > > Guillermo Schwarz > > Sun Certified Enterprise Architect > > > > > > > > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect --~--~---------~--~----~------------~-------~--~----~ Has recibido este mensaje porque estás suscrito a Grupo "ClubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
