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
> >
>
--~--~---------~--~----~------------~-------~--~----~
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.
-~----------~----~----~----~------~----~------~--~---
