Hola, la verdad estoy muy agradecido, un nivel excelente, jeje nunca me imaginaria que un tema terminaria en un blog, que bueno.
Carlos el ejemplo esta mas que claro, se nota muy detallado como el estado del cliente influye en la decision de que impuesto aplicar. Ahora bien primera consulta, (no me guie por lo nombres que se que son a solo ejemplo), pero para aplicar el patron State hiciste uso del Tipo de Cliente, ahora el tipo, no me suena a estado, o sea el state no aplicaria cuando una entidad pasa por un flujo (o workflow) y en este debe reaccionar de distintas formas?, por eso no veia este patron como aplicarlo. Es mas el State lo vi muy similar al Strategy, solo que en dos conceptos distintos, uno para flujo y el otro para funcionalidad (por funcionalidad me refiero aplicar un algoritmo especifico de calculo, que lod etermina uno). http://en.wikipedia.org/wiki/State_pattern http://en.wikipedia.org/wiki/Strategy_pattern Si ven los digramas de estas wiki, veran que son muy similares. En realidad el planteo original, era si se puede usar desde dentro estos patrones acceso a otros origenes de datos, para tomar la desicion de que concreto devolver? Igual por lo que veo en los ejemplos, todos pasan un objetos de dominio o un contexto, y esto son utilizados. En los ejemplos del Factory por ejemplo, a veces hacian uso de la lectura de un archivo de configuracion que les permitia determinar que concreto devolver, pero esto es damasiado estatico para tomar una desicion que depende del dominio. Consulta, en el ejemplo de Carlos, se nota que con el estado y un contexto alcanza para resolver todo, pero que sucederia si para saber que impuesto aplicar se necesita conocer si la empresa del cliente aplicar retenciones a las exportaciones o no, o sea el cliente en este caso se queda corto, se requiere conocer la empresa del mismo (supongamos que el cliente es el responsable de compra de una empresa) y de esta, si esta habilitado para aplicar este impuesto o no, en la compra. O sea esto se lo puede consultar directo desde dentro del patron, o es necesario (o recomendado) pasarselo desde fuera? Por ahi se me ocurre que podria resolverse desde el Contexto, en este caso sino me equivoco seria la clase Cliente (del ejemplo de Carlos). Que en realidad como bien marco Daniel no deberia tener el nombre Cliente, pero para el ejemplo queda mas que claro. Daniel, te comento, sabes que siempre tengo problemas con el punto que me pedis, cuando tengo que diseñar el dominio es un problema, por lo general las entidades simples se reconocen facilmente, pero las necesarias para agregar las responsabilidades es un drama, no se si a ustedes durante el diseño les sucede los mismo, esto se que pasa porque no soy un experto en el dominio, y estoy bastante limitado para decidir que nombre quedaria mejor. Se que el contecto es una trasaccion de venta de maquinaria pesada, y dependiendo de las empresas involucradas, se necesitara importar el producto, con todos los TAX que esto implica, u otros impuestos si es que el equipo es nacional. Pero esta info no solo sale del cliente que realiza la compra, sino que tambien se involucra la empresa a la que pertenece y esta implicada. Bueno al verdad impresionante la ayuda que brindan, esta muy bueno discutir estos temas, porque los libros todo bien pero a la hora de ponerlos en practica ahi la cosa cambia. Saludos Daniel Calvin <[EMAIL PROTECTED]> escribió: Hola Leandro Nos podes dar un poquitin mas de letra de tu caso, lo minimo como para mejorar el nombre y los artefactos que intervienen en el ejemplo. Gracias Daniel Calvin El día 1/11/07, Daniel Calvin <[EMAIL PROTECTED]> escribió: Noo, no sonaste enojado Che... Dame un rato y trato de hacerme un huequito pa ver el tema de los nombres. ( muchas veces me pasa que se convierte, eso de bautizar las clases, en una tarea mas compleja que la de diseñarlas.... :((, me imagino que no soy el unico que tiene ese problema.. ) Daniel El día 1/11/07, Carlos Peix < [EMAIL PROTECTED]> escribió: No, no me enojo :-), pero tenia que aclararlo. Elegi cuidadosamente las frases para no sonar enojado, pero no lo logre :-). Incluso estoy pensando algun cambio en los nombres para que el ejemplo no despierte dudas en el sentido que vos mencionas. Alguna sugerencia para cambiar los nombres de las clases y que sea un buen ejemplo de uso de los patrones y que al mismo tiempo no haga ruido desde el punod de vista de la distribucion de responsabilidades? Carlos Peix --------------------------------- From: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Calvin Sent: Jueves, 01 de Noviembre de 2007 10:41 a.m. To: patrones List Member Subject: [patrones] Factory Pattern aplicado al la logica de negocio Carlos No te me vayas a enojar!!!!, por favor. :)) Te juro que no era mi intención discutir ni criticar, solo remarque la cuestión para que si alguien toma la solución le de una vuelta de tuerca al diseño. Digamos que aproveche para hacer incapie en el donde o el que uno deberia mirar para poner estas cosas. Por eso al principio puse "critica constructiva". Mas que gracias por leerlo, gracias por escribirlo. :)) Te mando un abrazo. Daniel El día 1/11/07, Carlos Peix <[EMAIL PROTECTED]> escribió: Hola Daniel, Este es el riesgo de escribir codigo para contestar en una lista :-). Terminamos discutiendo el modelo que yo propuse como ejemplo en lugar de discutir el problema original. No conozco el dominio de Leandro, los conceptos TipoCliente, CalculadorImpuestos, etc., los elegi yo con el unico fin de mostrar como aplicar la combinacion State/Strategy. Ese codigo no pretende decirle a Leandro como resolver su dominio sino ejemplificar la aplicacion de los patrones en cuestion. Yo entendi del ultimo post de Leandro que tenia dudas sobre la implementacion de estos patrones. Visto como vos lo ves, tenes razon, conceptualmente no es adecuado el modelo. Gracias por tomarte el tiempo de leerlo. Carlos Peix --------------------------------- From: patrones@mug.org.ar [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Calvin Sent: Jueves, 01 de Noviembre de 2007 10:01 a.m. To: patrones List Member Subject: [patrones] Factory Pattern aplicado al la logica de negocio Hola Carlos Estuve mirando el ejemplito en el BLog. Puedo hacer una critica constructiva? En Cliente definis una propiedad del type TipoCliente // La clase Cliente public class Cliente { ... // Este metodo delega en el metodo del tipo de cliente public ICalculadorImpuesto ObtenerCalculadorImpuesto() { return tipoCliente.ObtenerCalculadorImpuesto( this ); } ... } Me da la sensación que cliente no es el experto en información para, aunque sea mediante otro artefacto ( TipoCliente ), obtener el calculador. En el dominio esa responsabilidad es seguramente de algun agente externo a cliente. Me refiero a que en ese contexto se le esta asignando a Cliente, aunque sea indirectamente, una responsabilidad que lo excede. Debería, a mi entender, existir un tercer artefacto, parecido o tu sugerencia de TipoCliente ( no lo llamaria de esa forma porque eso sugiere que esta muy pegado a Cliente), pero que sería el encargado de proveer en base a Cliente el o los Calculadores. La diferencia puede ser sutil pero no lo es, Cliente en el ejemplo pasa a ser muy rigida y acoplada, se adapta facil al cambio del calculador de impuestos pero lleva mucho equipaje en la mochila. El tema es discutible, pero me parece que sería mucho mas sano que eso fuera externo a Cliente. Si estuvieramos hablando de la categoría de IVA de Cliente mi enfoque seria distinto, ya que depende pura y exclusivamente del cliente, es una atributo muy concreto. Si estamos hablando de otro tipo de impuestos o cualquier otra cuestion que se calcula en base a otros atributos, por ejemplo la categoría de IVA y alguna otra cosa, o el tipo de documento y la nacionalidad, osea cuestiones que exceden un propiedad concreta, algo que debe ser inferido, esa funcionalidad, esa responsabilidad, debe ser externa a Cliente. Bueno hago el comentario porque me parece que aplica a como resolver el problema en general. No lo tomes como una crítica al ejemplo que propusiste. Creo que extraer esa responsabilidad de Cliente y buscar el responsable real mejora el diseño y la claridad de la aplicación, al mismo tiempo Cliente será mas Cohesivo y menos acoplado. Saludos Daniel Calvin El día 1/11/07, Carlos Peix <[EMAIL PROTECTED] > escribió: Hola Leandro, como el post se me hizo largo, lo coloque en el blog. http://carlospeix.blogspot.com/2007/11/refactoring-statestrategy.html Carlos Peix --------------------------------- From: patrones@mug.org.ar [mailto: [EMAIL PROTECTED] On Behalf Of Leandro Tuttini Sent: Miércoles, 31 de Octubre de 2007 05:39 p.m. To: patrones List Member Subject: [patrones] Factory Pattern aplicado al la logica de negocio Daniel, Carlos, mil gracias por los comentarios, van aclarando un poco el tema. Daniel sino por lo que veo tus comentarios apuntan a no agregar funcionalida o acoplar, el Factory a un repositorio. O sea me aconsejas que la implementacion de Factory reciba la info que necesita y que no los obtenga por si mismo. Como yo lo habia pensado el Factory seria el experto en la creacion del impuesto, como bien dice Daniel. Carlos, te comento la verdad se que estoy un poco flojo en temas de patrones, la verdad no sabria como cerrarlo con el State, aunque me dejaste la duda con el Strategy. Por lo que vi del Strategy en este es como que yo decido que estrategia aplicar en cada momento, sino entendi mal esta no se descubre en runtime. O sea al Strategy le digo aca esta mi contexto con esta info cargada, aca tenes la estrategia a aplicar, ahora ejecutate. La cuestion es que en este caso no se en tiempo de desarrollo que estrategia aplicar, salvo que codifique la logica para descubrirla, pero en ese caso estoy perdiendo encapsulamiento, ya que debo repetir esta logica cada vez que quiera saber que impuesto aplicar. Lo que deberia lograr es poder en runtime que impuesto aplicar a la transaccion, o sea que concreto de impuesto se debe aplicar. Y la macana es que no sale esta logica solo de un archivo de configuracion, como puedo ver en varios ejemplos. Muchas gracias Saludos Daniel Calvin <[EMAIL PROTECTED]> escribió: Hola Leandro La verdad no me cierra mucho, ni abstract factory, ni factory method, si bien entre los dos el que mas me suena para lo que queres hacer abstract factory. ( sobre todo porque genera una familia de artefactos ) Por ejemplo en cooperator para generar el código, ya que puede ser que tenga que generar tanto vb.net como c# y ademas parsear los scripts y el estilo de tagueado de los scripts puede cambiarse, por ahora solo usamos <% %>, pero puede ser cualquiera, el interprete y el parser se crean con una abstract factory. Para saber que pasarle como parametro yo le daria un giro a la cosa, en vez de pensar en que le psao, pensaria en que necesita. Ese artefacto en definitiva será el experto en información para el calculo de impuesto o, esa sería otra opcion, el experto en información para la creación de los calculadores de impuestos. La primera me gusta más. Ahora..., que necesita ese experto para disfrazarse de calculador de impuestos o de factory de esos calculadores. Yo trataría de pasarle algun o algunos objetos del dominio que sean representativos para ese experto, en todo caso aplicar segregación de interface para no acoplar mucho la cosa. Bue, tal vez me fui por las ramas.., el que mas aplica es abstract factory, pero me suena medio forzado. Saludos Daniel Calvin El día 31/10/07, Leandro Tuttini < [EMAIL PROTECTED]> escribió: Hola Carlos que tal. Paso a explicar con un poco mas en detalle. Tengo una transaccion bancaria a la que se le aplicaran impuestos, la cuestion es que la decision de que impuestos aplicar varia en base a info del cliente y su estado de cuentas, en realidad no se muy bien aun cual sera la logica aplicada para determinar que impuestos especifico aplicar, pero si se que del resultado de eso devolvera el concreto del impuesto. Por ejemplo si seran impuestos nacionalales, internacionales, etc, cada impuesto por supuesto tiene la logica de como se calcula. La cuestion es que este Factory deberia tal vez recibir un cliente y ademas consultar al repositorio el resto de la info en base a este. Justamente lo que no se es si es correcto que el Factory este atado a un objeto como parametro y ademas a la consulta a la db. O si implementarlo pasandole como parametro toda la info que necesite (tal vez con un objeto Context), y que solo aplique logica para resolver que devolver, sin consultar a nada externo. Espero se entienda un poco mas, sino paso mas detalles. Saludos Carlos Peix < [EMAIL PROTECTED]> escribió: Hola Lenadro, Podes describir un poco el caso real? es posible que el patron State sea mas adecuado pero para saberlo seria bueno disponer de mas informacion. Carlos Peix --------------------------------- From: patrones@mug.org.ar [mailto: [EMAIL PROTECTED] On Behalf Of Leandro Tuttini Sent: Miércoles, 31 de Octubre de 2007 10:19 a.m. To: patrones List Member Subject: [patrones] Factory Pattern aplicado al la logica de negocio Hola, que tal. Queria plantear una duda conceptual que por supuesto repercutira en la implementacion. La duda esta referida al patron Abstract Factory, aunque creo que el Factory Method tambien estaria incluido. En todos los papers y notas que pude ver este patron sera el encargado de decidir que concreto devolver en base al contexto. Ahora bien resulta que casi siempre es aplicado en la construccion de objetos de infraestructura como ser ventanas, botones, por ahi basados en el ambiente donde se ejecuta, y este resuelve en base a la lectura de un archivo de configuracion. Ahora bien que sucede si se quiere aplicacar este patron a reglas de negocio, pero que dedida en base a informacion de una transaccion, (por ejemplo, info del cliente), en este caso la configuracion no serviria. Este tipo de caso como se implementaria, o sea se deberia crear un objeto Context que se info especifica y se lo pasaria al constructor del Factory, o se puede leer desde la base de datos, caso que el cliente, por ejemplo, no alcance para resolver que objeto concreto crear. Es correcto que la implementacion del factory este atado a la lectura de un repositorio? En realidad no al concreto del repositorio, pero si a su interfaz. Bueno seria esta simplemente la duda, como utilizar el patron de creacion cuando se trata de aplicarlo a objetos de negocio. Saludos --------------------------------- Los referentes más importantes en compra/venta de autos se juntaron: Demotores y Yahoo!. Ahora comprar o vender tu auto es más fácil. Visitá http://ar.autos.yahoo.com/ --------------------------------- Los referentes más importantes en compra/venta de autos se juntaron: Demotores y Yahoo!. Ahora comprar o vender tu auto es más fácil. Visitá http://ar.autos.yahoo.com/ -- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional --------------------------------- Yahoo! Noticias Todo lo que tenés que saber sobre Elecciones Presidenciales 2007 encontralo en Yahoo! Noticias. http://ar.news.yahoo.com/elecciones2007/ -- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional -- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional -- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional -- Daniel A. Calvin Cooperator Team Member http://www.cooperator.com.ar Microsoft Certified Professional --------------------------------- Yahoo! Noticias Todo lo que tenés que saber sobre Elecciones Presidenciales 2007 encontralo en Yahoo! Noticias. http://ar.news.yahoo.com/elecciones2007/
