On Thu, 2003-01-30 at 22:03, Jose San Leandro wrote: > Lo primero que surge aquí es el concepto de "herencia entre clases Action". > Como en muchos otros casos, se utiliza la herencia sin que tenga mucho > sentido en el diseño, simplemente para no duplicar el código. > En realidad, las clases Action, teóricamente, simplemente deberían delegar la > lógica en el objeto de negocio correspondiente, pero aunque sólo sea una > linea la herencia evita la duplicidad de esa llamada. En el caso que expongo, > además de la llamada al objeto de negocio se realizan unas simples > validaciones de los datos de entrada.
Como bien dices, el abuso de las relaciones de herencia es un problema muy común en muchos diseños OO. Como sabes, uno de los principios establecidos en el GoF es el de favorecer la delegación a objetos sobre la herencia de clases. Para hacerles caso, se me ocurre que en lugar de recurrir a herencia pura o a un patrón "template method" que al final también se basa en la herencia, el patrón "strategy" consigue lo mismo pero mediante delegación que siempre es una relación mucho menos fuerte que la herencia. > > Resumiendo, mis duda son: > ¿Cómo se deberían interpretar las relaciones entre entidades Action dentro del > patrón mvc? A mi juicio, la gran ventaja de MVC es poder reutilizar los componentes del modelo entre diferentes aplicaciones, gracias al nivel de desacoplo entre presentación y modelo que se consigue con el controlador, pero no tanto reutilizar los elementos del controlador. De todas formas, para el problema que planteas, no sé si podría servir definir Action de alto nivel formados por otros Action más básicos. Los Action en Struts representan una aplicación del patrón "command", así que esto otro sería "composite" + "command" :-) De esta manera los Action básicos sí se reutilizarían entre las diferentes subaplicaciones web, sms y wap. > ¿Son los Action parte del controller? Yo diría que en un buen diseño son parte del controlador y en uno no tan bueno del modelo. Es decir, lo suyo sería que los Action delegasen en los objetos de la lógica de negocio. Incluso, si me apuras empleando un "business delegate" para que la implementación concreta del modelo (EJB, CORBA, JDO, JavaBeans...) sea transparente al controlador y el acoplamiento sea menor. La otra opción es introducir más inteligencia en los Action, de modo que contengan la lógica de negocio. Esto sólo me parece válido si la aplicación es tan sencilla que otra cosa supondría sobrediseñar o si no se contempla la posibilidad de reutilizar los componentes del modelo. > ¿Cómo se podría definir más explícitamente el contrato > (éxito/fracaso/error/etc) que debe satisfacer cada Action? Nada nuevo que aportar :-( > ¿Se pueden considerar los Action los "eventos" entre el modelo y la vista, >gestionados a > través del controlador? En la implementación de MVC que hace Struts, los Action son exactamente eso. Representan qué acciones realizar sobre el modelo, pero no cómo efectuarlas. > > Gracias. -- Rafael Luque, <[EMAIL PROTECTED]> Clave PGP: http://www.orange-soft.com/people/luque/clavepgp Metadatos RDF: http://www.orange-soft.com/people/luque/contacto.rdf --------------------------------------------------------------------- Para eliminar la suscripci�n, mail a: [EMAIL PROTECTED] Para comandos adicionales, mail a: [EMAIL PROTECTED]
