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
