No es que no te crea, pero ¿tienes alguna referencia que compruebe lo que dices?
Una cosa es no ser querido, y otra muy distinta es estar equivocado. Rebeca Wirfs-Brock: "Looking for Powerful Abstractions" in the January/February 2006 issue. Vol 23, No.1. This column explains why identifying reasonable classes isn't as simple as underlining nouns or modeling "real world" concepts. Download PDF <http://www.wirfs-brock.com/PDFs/013-015.pdf> (177K) Tomado de http://www.wirfs-brock.com/Resources.html Esto básicamente contradice la idea de que basta con encontrar los objetos y modelarlos en jerarquías. No dice que esté mal, sólo que no es suficiente. El principal problema de este enfoque es que se llega a callejones sin salida. Dicho de otra manera, es una mala recomendación, aunque es buena si uno no tiene otra alternativa. Quienes tienen algo que decir al respecto prefieren usar casos de uso. La idea fundamental del inventor de los casos de uso (Ivar Jacobson en Object Oriented Software Engineering) es: 1. Encuentra a los usuarios y a los stake holders del sistema. 2. Para cada usuario y stakeholder declara sus objetivos. 3. Encuentra una solución para esos objetivos. 4. Para cada usuario encuentra un "caso" que al ser "usado" resuelve al menos uno Sólo una vez que se ha determinado los casos de uso del sistema, recomienda este señor encontrar los objetos, pero "sólo como una manera de encontrar una solución al problema general de resolver los casos de uso". Hay varias metodologías que están relacionadas a OO y que no parten de esa (a mi juicio) "sana" base. Partir modelando los objetos internos del sistema es como modelar una solución no basada en lo que el usuario necesita, sino en lo que creo que soy capaz de hacer. Eso tiene sentido cuando se aplica una técnica de modelamiento bottom up. Lo que propone el señor Jacobson es una estrategia top down. Está demás decir que ambos tienen razón. No es posible modelar algo desde el punto de vista de los requerimientos y seguir así descomponiendo indefinidamente. En algún momento debes llegar al "yo puedo" hacer esto. De la misma manera no tiene sentido hacer todo bottom-up, ya que puedes terminar con un sistema que funciona muy bien, pero que nadie quiera. SI sigues ambas ideas al mismo tiempo se habla de "meet in the middle". Existen proponentes que indican que modelar un sistema botton-up tiene la ventaja de que si no entendiste los requerimeintos, es fácil cambiar el sistema (siempre que hayas seguido ciertas reglas). Eso me parece lo más cuerdo y es la base de la metodología XP. Hasta donde entiendo hay varios proponentes de XP en esta lista, aunque también hay varios que lo odian. El punto que quería hacer es que si te dedicas a crear jerarquías de objetos sin tener los requerimientos en mente, no llegas a nada cuerdo. Saludos cordiales, Guillermo. 2008/9/23 Hernan Wilkinson <[EMAIL PROTECTED]> > Mi respeto por Bertrand Meyer termina donde él empieza a modelar las > excepciones como números... Ese paper que sitas es muy viejo y luego se > retractó del mismo. > Por otro lado, Meyer no es muy querido en la comunidad objetos, sino > averigua un poco los encontronazos que tuvo con gente en OOSPLA como Allen > Wirfs-Brook, Ralph Jonhson, etc. > > > 2008/9/23 Guillermo Schwarz <[EMAIL PROTECTED]> > > 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 -~----------~----~----~----~------~----~------~--~---
