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
