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/ 

Responder a