- Good example for Abstract factory pattern in C#?
- What are the advantages of the Abstract factory pattern in C#?
- How to use C# generics with the Abstract factory pattern?
- How to unit test with the Abstract factory pattern?
相关问题
- How do I create a multidimensional array of object
- Name for a method that has only side effects
- What is a correct approach to manage test data usi
- Can a [GoF]-ConcreteSubject override the notify me
- Shared common definitions across C/C++ (unmanaged)
相关文章
- Can the “dynamic” type vary safely in a generic co
- Builders in Java versus C++?
- Check if a datetime is in same week as other datet
- Why doesn't there exists a subi opcode for MIP
- “Adapter” or “adaptor”?
- Adding additional attributes to each property of a
- Is copy-and-paste coding ever acceptable?
- DDD Architecture - Where To Put Common Methods/Hel
First of all, I would suggest you to read about the Abstract Factory pattern, for example here. Now I will try to explain why you would use this pattern.
Normally, if you use the Factory pattern, you will create objects in a Factory. The problem arises when you have multiple implementation of a given class (or classes). Now, those multiple implementations are grouped. You will use the
Abstract Factory pattern
when you have a factory, but you would like to group the creating of objects per group.Okay, above explanation might not be completely clear, so I will give you an example.
Let's say you have a class library with data agents. Data agents provide you methods to access and store different data. Of course, there are multiple ways of storing your data. For example: in a database, in XML file, over a service, . For each of these possible ways, you would like to have data agents. Now the problem is, you don't want that someone uses the DataAgentA for XML files together with DataAgentB for database (let's assume that we have entities A and B). The user should use only one storage engine.
Let me introduce you the Abstract Factory pattern.
You will make sure that users cannot directly instantiate your Data Agents, but they will have to get these data agents out of a factory. (An extra advantage is, that when you use for example a database (EF), you can do internal wiring to make sure your Data Agents use the same context, etc.) How do we accomplish this? We set the constructor of our data agents to ´internal´. Apart from that, we create different factories for each storage engine. Now, since those factories all do the same, we also have these interfaced (just like our data agents, since they all have to do the same, right!?).
Below we have our interfaces. Basically this is the factory pattern, but only now instead of about classes, we are talking about interfaces.
Now for the two agents, we have two possible implementations, one for XML and one for database storage (again: this is an example, you can have as many implementation types as you want). Those implementations would look like this (see below). Please note that I made the constructor
internal
! This is needed for the part that comes after this code block.Now as the constructors are internal. This causes that you cannot instantiate those classes outside the assembly, which is generally what you do with these kind of cases. Now we have to create our factories.
Since both factories implement the
IAgentFactory
interface, the user can easily change ofAgentFactory
implementation (if he, in this case, wants to use a different storage engine) without having to change any other code he wrote (against the agents), as long as he programmed against the interfaces (obviously).Above explanation hopefully answers your questions (1) and (2).
Answering your question (3).
You can still use generics, this doesn't change any bit when you use an Abstract Factory pattern. Of course, you will have to create generic factory methods (the create methods), but that shouldn't be any problem.
Answering your question (4).
Just the same as you would unit test any other class. Only one thing will be different.
Since you probably also want to test the constructor of your classes (and maybe other internal methods), you need to make the internal constructors (methods) visible to your unit test project (and you don't want to change the
internal
topublic
). This is easily done by adding the following line to yourAssemblyInfo.cs
file of your project (the project where your factory and classes are in):You can find more information (and remarks) about the InternalsVisibleTo attribute on MSDN.
I hope this kind of answers your question.