Creoque tu ejemplo simplifica demasiado el asunto. No se trata de pensar en cualquier cosa.
Pensar en objetos no es necesariamente abstraer, ya que una vez que haz llegado al nivel de objetos no puedes seguir abstrayendo, a menos que empieces a bajar en la jerarquìa de clases hasta llegar a la clase Object... Sí, es notable. También es notable que no lo hayas leído por ti mismo. ¿No existe acaso un principio que se llama DRY: Don't Repeat Yourself? Esto del código repetido saca roncha porque seamos honestos, la mayor parte de los proyectos nada en código repetido y pensamos que estamos "ok", sólo porque tenemos un par de objetos parados por ahí, que no son más que data holders. No nos veamos la suerte entre gitanos... JA JA JA 2008/5/7 Emilio Oca <[EMAIL PROTECTED]>: > > Hola, como para insistir no mas. > > Si el objetivo fuera reducir código y desarrollar enfocados en el > código, que nos impide pensar y modelar enfocados en condicionales, > jumps y branchs, para el caso todo se reduce a eso. O mejor aun > pensemos en assembler. > > No, pensamos y nos enfocamos en objetos con la idea de modelar el > dominio del problema, de abstraernos, de desarrollar entidades > cercanas a los elementos con los que realmente tenemos que lidiar. No > código. El código es un medio, como son los jumps, como es el > essembler. > > Guillermo, es notable como aseguras con tanta energía que el enfoque > de un paradigma es ahorrar código entre otras afirmaciones, Y páginas > mas a bajo compartís como te asombras de entender que las librerías > son mas útiles cuando las concebís como un medio de abstracción y no > como código no repetido. > > Saludos. > > Emilio > > On 5/7/08, Gabriel <[EMAIL PROTECTED]> wrote: > > 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. -~----------~----~----~----~------~----~------~--~---
