Dije que era un ejemplo tìpico, no que no hubiera otra soluciòn posible...
Eso de que para tener OOP sea necesario tener clases, es verdad en Smalltalk, pero no es verdad en Lisp o en Self, como alguien ya mencionó en este thread. Tambièn opino que la discusión está agotada... ;-( 2008/5/8 Gabriel <[EMAIL PROTECTED]>: > Realmente no comparto tus ideas Guillermo, en ese ejemplo obviamente se > puede hacer un diseño mucho mejor que el de herencia multiple (que no tiene > sentido). Pero bueno, es otro tema y creo que esta discución está agotada. > Si lo de definiciones de enciclopedia te referis a mi, no creo que sea mi > caso, laburo en la industria y pude comprobar en mi experiencia personal > algunas cosas (que obviamente podria estar equivocado, como cualquier > mortal). > Igual lo que me parece peor es que no lees lo que escribo, porque insistis > en que OOP implica tener clases, y esto NO ES ASI. > que es un objeto? un componente de tu programa que sabe recibir mensajes y > dar una respuesta a ellos (y mira que no pense demasiado la definicion). > > Saludos > Gabriel > > > 2008/5/8 Emilio Oca <[EMAIL PROTECTED]>: > >> >> Tomo tus comentarios con la seriedad de alguien que puede argumentar esto: >> > Y el tìpico ejemplo de còmo las jerarquìas fallaban en OOP era la clase >> > empleado con 2 sublclases: empleado temporal y secretaria, que tienen >> clases >> > distintas, ya que los sueldos y los incentivos son diferentes en ambos >> casos >> > y por lo tanto sus mètodos han sido overriden. ¿Què hacemos con una >> > secretaria temporal? La respuesta en esa tiempo era usar herencia >> múltiple >> > en C++, pero aprendimos dolorosamente que no hay manera de implementar >> la >> > herencia múltiple de manera que no tenga defectos de implementación. Si >> no >> > existe una implementación posible, el problema es de diseño y no de >> > implementación. >> Te sugiero revises tu modelo antes de asegurar que no existe solucion >> satisfactoria posible. >> Y lo mismo al momento de sacar tantas otras conclusiones. >> >> Emilio >> >> >> On 5/8/08, Guillermo Schwarz <[EMAIL PROTECTED]> wrote: >> > Sì, bueno, al parecer estamos entre los que no tienen idea de lo que >> estàn >> > hablando y los que tienen un enfoque enciclopèdico que màs bien reùnen >> > definiciones y las encuadernan. No tiene nada de malo tener un >> conocimiento >> > enciclopédico, lo único malo es que es difícil tener una discusión con >> una >> > enciclopedia, ya que sabe de todo un poco, pero nada en profundidad. >> > >> > No es una crítica, pero pensaba que se podía discutir respecto de estos >> > temas, y al parecer no. O presentas las ideas ya digeridas para que el >> resto >> > las consuma como si fueran televidentes o se toman como grandes >> > provocaciones al status quo y salen con arengas que no son propias de >> > profesionales. >> > >> > Si las ideas no "provocan", ¿cómo se podría pretender aprender algo? >> Esto al >> > parecer se malentiende como "trolling", digo, algo de provocación debe >> > haber, pero terminan en rencillas personales con ataques que tienen más >> que >> > ver con falacias ad hominem que con argumentos vàlidos. >> > >> > Las ideas que presenté acá son sumamente básicas. Las reacciones son >> propias >> > de fanáticos analfabetos. Yo tambièn soy fanàtico de la orientaciòn a >> > objetos, pero no se trata de defenderla a ultranza, debes entender hasta >> > dònde es posible aplicarla y cuando la teorìa empieza a fallar. Todos >> > sabemos que las clasificaciones zoológicas son jerarquìas similares a >> las >> > jerarquías de herencia de clases y su propòsito es hacer una >> clasificaciòn >> > (por eso se llaman "clases" en vez de "tipos"), pero se encuentran con >> el >> > problema del ornitorrinco que es mamìfero y pone huevos ¿bajo què rama >> lo >> > ponemos?. Este ornitorrinco salìa en la tapa de un conocido libro de >> > orientaciòn a objetos de principios de los 90's y casi como en broma >> este >> > problema no era tratado en el libro, supongo que por la misma razòn que >> > escuchamos tanto berrinche en este thread: hay gente que se espanta con >> las >> > contradicciones y se les viene el mundo abajo. A todos estos les tengo >> una >> > buena y una mala noticia. >> > >> > Buena noticia: Las contradicciones no echan el mundo abajo. >> > Mala noticia: El mundo està lleno de contradicciones. >> > >> > Y el tìpico ejemplo de còmo las jerarquìas fallaban en OOP era la clase >> > empleado con 2 sublclases: empleado temporal y secretaria, que tienen >> clases >> > distintas, ya que los sueldos y los incentivos son diferentes en ambos >> casos >> > y por lo tanto sus mètodos han sido overriden. ¿Què hacemos con una >> > secretaria temporal? La respuesta en esa tiempo era usar herencia >> múltiple >> > en C++, pero aprendimos dolorosamente que no hay manera de implementar >> la >> > herencia múltiple de manera que no tenga defectos de implementación. Si >> no >> > existe una implementación posible, el problema es de diseño y no de >> > implementación. >> > >> > A nadie le gusta la crítica, eso se los aseguro, pero es desagradable >> que >> > los temas no se puedan discutir, incluso si a alguien no le gustan, ya >> que >> > en los proyectos la gente está principalmente enfocada a lograr los >> > objetivos del proyecto, de modo que no tiene tiempo para discusiones >> > "filosòficas". ¿Si no hay cabida en estos grupos, dònde hay un espacio >> para >> > conversar estos temas? >> > >> > De todos modos en todos los proyectos hay temas desagradables y alguien >> debe >> > ser capaz de manejarlos. Hay personas que rehuyen de los temas >> desagradables >> > y dejan que los hagan otros. Generalmente esos son los jefes. Asì que >> Emilio >> > y Esteban deben ser jefes o se estàn perdiendo. >> > >> > Gracias por la referencia a Dan Ingalls. En general creo que la gente >> que >> > critica OOP es bastante inteligente y creo que Dan Ingalls no està >> aportando >> > nada nuevo a la discusiòn, su descripciòn más bien es una defensa que >> > alguien harìa en los años 70's, cuando Lisp y Smalltalk estaban contra C >> y >> > Pascal. Supongo que històricamente su defensa de Smalltalk debe tener >> valor, >> > pero ahora que OOP ha ganado y los lenguajes funcionales parece que se >> van a >> > tomar el mundo, creo que no tiene mucho sentido. >> > >> > La principal crìtiica a OOP, o por lo menos la que a mì me hace màs >> sentido, >> > es que las clases no pueden cambiar en tiempo de ejecuciòn (esto no es >> > verdad en Smalltalk, pero si miramos el 99% de los programas escritos en >> > Smalltalk veremos que no se crean clases en tiempo de ejecuciòn). >> > >> > Esto lo veo como un problema sólo cuando estás tratando de hacer cosas >> > realmente inteligentes y entiendo que los defesores del status quo digan >> que >> > eso no es del mundo real, ya que son simples consumidores de tecnología >> y no >> > son capaces de crearla. Son programadores con mentalidad de usuario, el >> > mundo para ellos es estático y los cambios les significan un problema. >> Mi >> > interès es apelar a aquellos a los que el cambio les interesa y >> necesitan >> > investigar cosas nuevas, como dice Alan Kay, "la mejor manera de >> predecir el >> > futuro es inventarlo". >> > >> > Lo otro que me gustarìa aclarar es que no comparto la idea de Stepanov >> de >> > que primero hay que encontrar los algoritmos genèricos y finalmente los >> > objetos. Creo que el valor que tiene OOP es que puedo partir por lo que >> > entiendo e ir modelando hacia lo que no entiendo (y que voy entendiendo >> en >> > el camino, a medida que avanzo). Lo que sì le concedo a Stepanov es que >> es >> > difìcil programar max en Java a diferencia de lo que ocurre con STL, >> pero >> > aún así se puede. >> > >> > Lo que encuentro pobre de Stepanov es que piensa que lo importante es >> > encontrar "algoritmos bonitos", lo que invariablemente significa >> encontrar >> > código valioso del cual se enamora, ya que el resto "no es valioso". En >> OOP >> > se suele escribir código desagregado, donde el algoritmo está esparcido >> y >> > por lo tanto no hay un núcleo central que hace todo, sino que cada parte >> > tiene su responsabilidad. >> > >> > Esto lleva a código mucho más simple y más poderoso que en el caso de >> STL, >> > que desde mi punto de vista es simplemente el Visual Basic de C++, es >> decir, >> > permite que programadores mediocres creen còdigo eficiente, sin entender >> > bien lo que estàn haciendo, y mientras STL les provea lo que necesitan >> estàn >> > bien, si se salen un poco de lo que STL les provee, "lo lamentamos, esa >> > función aún no está implementada". Esto es tìpico del nivel usuario, que >> > prefiere un mundo ordenado donde todas las respuestas estàn dadas y a la >> > mano. >> > >> > Al menos desde mi punto de vista los programadores son aquellos que no >> están >> > resolviendo siempre los mismos problemas, sino los que crean bibliotecas >> > para los problemas repetidos y se enfrascan en problemas nuevos. >> > >> > Otra de las críticas a Smalltalk, y creo que es la crítica màs fuerte, >> es >> > que no existe una formalizaciòn de lo que significa un objeto. "un >> objeto >> > tiene estado y comportamiento " es una definiciòn tan vaga que no es >> posible >> > razonar respecto de ella y formalismos como el modelo relacional y los >> > lenguajes funcionales probablemente terminen desarrollando los >> formalismos >> > para capturar la escencia de la programación orientada a objetos. >> > >> > Respecto de los principios de la orientación a objetos, éstos son la >> base de >> > los patrones GoF. Entiendo que siendo este un grupo de Smalltalk no >> > necesariamente todos pensarán que los patrones GoF son realmente algo >> > provechoso. >> > >> > http://www.apwebco.com/gofpatterns/index.html >> > >> > Y ya que este tema parece que no tiene cabida en este grupo, ¿què les >> parece >> > el tema propuesto por Paul Graham, respecto de que para tener èxito en >> una >> > empresa es mejor programar bottom up que programar top down? >> > >> > http://www.paulgraham.com/progbot.html >> > >> > Saludos, >> > Guillermo. >> > >> > >> > 2008/5/8 Gabriel <[EMAIL PROTECTED]>: >> > >> > >> > > Me gustaria que se dejen de lado la descalificación. La discución está >> por >> > demás interesante (por lo menos a mi me parece), no dejemos que se >> arruine. >> > > >> > > Guillermo, a mi me parece que quiza tenemos definiciones distintas de >> las >> > cosas y eso trae mas confución. Según lo que decis que leiste en ese >> texto >> > habla de que la orientación a objetos es una farsa porque las clases >> tienen >> > ciertos problemas. Por ejemplo, segun entendi el problema que nombras >> ahi es >> > que te obligan a generalizar desde el principio, es decir, creas una >> clase >> > pero todavia no tenes las instancias! entonces estas generalizando sobre >> > algo que no tenes idea todavia (o tenes una idea vaga). OK >> > > En primer lugar, un ambiente de objetos no tiene por que tener clases, >> no >> > es un requisito. En un ambiente de objetos los programas se defien a >> partir >> > de OBJETOS QUE COLABORAN ENVIANDOSE MENSAJES. >> > > Por ejemplo, Self es un ambiente de objetos sin clases, esta basado >> en >> > prototipos y delegación. Para crear un objeto se clona otro, no hay que >> > tener clases. >> > > Sin embargo, independientemente de esto, no creo que el mecanismo de >> > subclasificación sea necesariamente tan malo como plantea ese texto. >> Cuando >> > un modelo va madurando, se pueden hacer generalizaciones y no esta mal. >> El >> > estar obligado a usar clases es quiza una incomodidad, pero no un >> > impedimento para hacer buenos diseños. >> > > También hay que tener en cuenta que cuando hacemos una jerarquía, esa >> > jerarquía modela solo un punto de vista. Un punto de vista que nos es >> util >> > en el dominio que estamos manejando. >> > > Cuando Aristoteles armo la primer jerarquía de los seres vivos >> > (vertebrados e invertebrados; peces, anfibios, reptiles, etc....) es mas >> que >> > claro que uso criterios en algún punto arbitrario para definir las >> > diferentes clases. Podría haberlos clasificado en función de como esta >> > compuesto el tegido cutaneo (mande fruta para dar un ejemplo). Pero para >> > analizar ciertas cosas, diferentes puntos de vista pueden ser utiles. >> > > >> > > Con respecto a "OOP modela adecuadamente el mundo", me parece una >> frase >> > media vaga, OOP no modela el mundo. Uno puede utilizar un ambiente de >> > objetos para modelar parte de un dominio, y tratar de que eso que >> estamos >> > modelando refleje lo mas posible la porcion esa de la realidad en >> cuestión y >> > eso tiene varias ventajas. En primer lugar reduce el gap semantico >> > http://es.wikipedia.org/wiki/Intervalo_sem%C3%A1ntico y >> > hace que dos personas puedan entender y comunicar mejor, por lo tanto >> > trabajar mas en armonia. En segundo lugar, la complejidad de tu modelo >> > siempre va a estar atadada a la complejidad del dominio modelado y no >> > deberia agregar mas complejidad (algo que sucede en otros lenguajes). >> > > Mucha gente cree que hay que modelar la realidad hasta el mas minimo >> > detalle. Eso, en primer lugar es imposible. Y en segundo lugar no es >> > necesario. Es como decir que si yo quiero calcular el tiempo que me >> llevaría >> > llegar a Mar del Plata, tenga que modelar el comportamiento del universo >> > entero y tener en cuenta todos los infinitos factores. Obviamente que >> puedo >> > utilizar un modelo acotado y simplificadisimo y me va a recontra servir >> para >> > el problema que quiero resolver. De eso se trata, hagamos modelos >> > simplificados y acotados, pero que reflejen lo mas posible lo que >> estamos >> > modelando! >> > > >> > > Con respecto a lo que decia Alan Kay de que tendria que haberla >> llamado >> > orientacion a mensajes, Alan kay no se referia a eso, si no mas bien a >> que >> > el late binding es vital para la orientacion o objetos. Alan también >> dijo >> > que se sigue construyendo software como los egipcios las piramides, y se >> > referia a mucho de esto que estamos hablando. >> > > >> > > Los principios de Smalltalk estan basados en todo esto también, te >> dejo un >> > texto de Dan Ingalls, principal arquitecto de Smalltalk-80: >> > >> http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html >> > > si tenes ganas lee principalmente la seccion "Language" >> > > >> > > Conclusión, la clasificación no es el único mecanismo para compartir >> > comportamiento, pero tambien es util. Se podría combinar con otros como >> la >> > delegación y prototipos para etapas mas experimentales y de >> descubrimiento >> > del dominio. >> > > >> > > Saludos. >> > > Gabriel >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > 2008/5/8 Esteban A. Maringolo <[EMAIL PROTECTED]>: >> > > >> > > >> > > >> > > >> > > > >> > > > 2008/5/8 Emilio Oca <[EMAIL PROTECTED]>: >> > > > >> > > > > >> > > > > On 5/7/08, Guillermo Schwarz <[EMAIL PROTECTED]> >> wrote: >> > > > > > Creoque tu ejemplo simplifica demasiado el asunto. No se trata >> de >> > pensar en >> > > > > > cualquier cosa. >> > > > >> > > > >> > > > > Quizás mi error es pensar que entendés de los temas de los que >> > hablás, >> > > > > esta frase me deja esa duda. >> > > > >> > > > Nadie resiste un archivo.... >> > > > >> > > > >> > < >> http://groups.google.com/group/clubSmalltalk/search?group=clubSmalltalk&q=Troll >> > >> > > > >> > > > >> > > > -- >> > > > Esteban A. Maringolo >> > > > [EMAIL PROTECTED] >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> > >> > >> > -- >> > 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. -~----------~----~----~----~------~----~------~--~---
