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
