Patrón de fábrica abstracto

Question

1. ¿Buen ejemplo para patrón abstracto de fábrica en C#?
2. ¿Cuáles son las ventajas del patrón abstracto de fábrica en C#?
3. ¿Cómo usar los genéricos C# con el patrón abstracto de fábrica?
4. ¿Cómo probar la unidad con el patrón abstracto de fábrica?

Answer 1

Antes que nada, le sugiero que lea sobre el patrón Abstract Factory, por ejemplo here. Ahora intentaré explicar por qué usarías este patrón.

Normalmente, si utiliza el patrón de fábrica, creará objetos en una fábrica. El problema surge cuando tienes una implementación múltiple de una clase (o clases) determinada. Ahora, esas implementaciones múltiples están agrupadas. Utilizará Abstract Factory pattern cuando tenga una fábrica, pero le gustaría agrupar la creación de objetos por grupo.

De acuerdo, la explicación anterior podría no estar completamente clara, así que le daré un ejemplo.

Digamos que tiene una biblioteca de clases con agentes de datos. Los agentes de datos le proporcionan métodos para acceder y almacenar diferentes datos. Por supuesto, hay varias maneras de almacenar sus datos. Por ejemplo: en una base de datos, en un archivo XML, en un servicio,. Para cada una de estas formas posibles, le gustaría tener agentes de datos. Ahora el problema es que no desea que alguien use el DataAgentA para archivos XML junto con DataAgentB para la base de datos (supongamos que tenemos entidades A y B). El usuario debe usar solo un motor de almacenamiento.

Déjame presentarte el patrón Abstract Factory.

Se asegurará de que los usuarios no puedan instanciar directamente sus Agentes de datos, pero tendrán que sacar estos agentes de datos de una fábrica. (Una ventaja adicional es que cuando utiliza, por ejemplo, una base de datos (EF), puede realizar un cableado interno para asegurarse de que sus Agentes de Datos usan el mismo contexto, etc.) ¿Cómo logramos esto? Establecemos el constructor de nuestros agentes de datos en 'interno'. Además de eso, creamos diferentes fábricas para cada motor de almacenamiento. Ahora, dado que todas esas fábricas hacen lo mismo, también tenemos estas interfaces (al igual que nuestros agentes de datos, ya que todos tienen que hacer lo mismo, ¿no?).

A continuación tenemos nuestras interfaces. Básicamente, este es el patrón de fábrica, pero solo ahora en lugar de aproximadamente clases, estamos hablando de interfaces.

public interface IAgentA 
{ 
    // Add some methods here! 
} 

public interface IAgentB 
{ 
    // Add some methods here! 
} 

public interface IAgentFactory 
{ 
    IAgentA CreateAgentA(); 
    IAgentB CreateAgentB(); 
} 

Ahora para los dos agentes, tenemos dos posibles implementaciones, uno para XML y otro para el almacenamiento de base de datos (una vez más: este es un ejemplo, puede tener tantos tipos de implementación como desee). Esas implementaciones se verían así (ver más abajo). Tenga en cuenta que hice el constructor internal! Esto es necesario para la parte que viene después de este bloque de código.

public class AgentA_Xml : IAgentA 
{ 
    internal AgentA_Xml() 
    { /* Construction here */} 

    // IAgentA method implementations 
} 

public class AgentB_Xml : IAgentB 
{ 
    internal AgentB_Xml() 
    { /* Construction here */} 

    // IAgentB method implementations 
} 


public class AgentA_Database : IAgentA 
{ 
    internal AgentA_Database() 
    { /* Construction here */} 

    // IAgentA method implementations 
} 

public class AgentB_Database : IAgentB 
{ 
    internal AgentB_Database() 
    { /* Construction here */} 

    // IAgentB method implementations 
} 

Ahora como los constructores son internos. Esto hace que no pueda crear instancias de esas clases fuera del ensamblado, que generalmente es lo que hace con este tipo de casos. Ahora tenemos que crear nuestras fábricas.

public class XMLAgentFactory : IAgentFactory 
{ 
    public IAgentA CreateAgentA() 
    { 
     return new AgentA_Xml(); 
    } 

    public IAgentB CreateAgentB() 
    { 
     return new AgentB_Xml(); 
    } 
} 


public class DatabaseAgentFactory : IAgentFactory 
{ 
    public IAgentA CreateAgentA() 
    { 
     return new AgentA_Database(); 
    } 

    public IAgentB CreateAgentB() 
    { 
     return new AgentB_Database(); 
    } 
} 

Dado que ambas fábricas implementan la interfaz IAgentFactory, el usuario puede cambiar fácilmente de AgentFactory aplicación (si es que, en este caso, quiere usar un motor de almacenamiento diferente) sin tener que cambiar cualquier otro código que escribió (en contra los agentes), siempre y cuando programado contra las interfaces (obviamente).

La explicación anterior responde con suerte sus preguntas (1) y (2).

1. buen ejemplo para Abstract Factory en C#?
2. y ¿cuáles son las ventajas del patrón abstracto de fábrica en C#?

Respondiendo a tu pregunta (3).

1. Cómo # genéricos uso C con el modelo abstracto de la fábrica?

fijas que se pueden utilizar medicamentos genéricos, esto no cambia cualquier bit cuando se utiliza un patrón Abstract Factory. Por supuesto, tendrá que crear métodos genéricos de fábrica (los métodos de creación), pero eso no debería ser ningún problema.

Respondiendo a tu pregunta (4).

1. ¿Cómo prueba de la unidad con el patrón de fábrica abstracta?

Igual que lo haría con la prueba unitaria de cualquier otra clase. Solo una cosa será diferente.

Dado que probablemente también desee probar el constructor de sus clases (y tal vez otros métodos internos), debe hacer que los constructores internos (métodos) sean visibles para su proyecto de prueba de unidad (y no desea cambiar el internal a public). Esto se hace fácilmente añadiendo la siguiente línea a su archivo AssemblyInfo.cs de su proyecto (el proyecto donde su fábrica y las clases están en):

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("My.UnitTest.Namespace")] 

Puede encontrar más información (y comentarios) sobre el atributo InternalsVisibleTo en MSDN .

Espero que este tipo de respuestas a su pregunta.