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
> > 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
>
> >
>
>
>
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
http://www.clubSmalltalk.org
-~----------~----~----~----~------~----~------~--~---
