Finally, I am up with the article that took lot of search and deep understanding of the concept of one of the most important design patterns, I will try to explain about the Abstract factorypattern. At first, it may sound quite similar to the Factory pattern, but they are not the same. Abstract factory pattern is at one level above then the Factory pattern that i discussed earlier in one of my posts here.

When i started to get an idea of this pattern, i went on & kept scratching my head for days, with lots of articles on the internet, but all of them had the same definition :

“Results in an, interface which provides families of related or dependent objects without providing their concrete classes.”

I was not able to figure out what exactly does families of related or dependent objects in the definition meant. Finally, I was able to figure out the understanding of this definition, by comparing some of the articles that provided good real world examples & related their examples with my example from the real world. So the result i concluded, is explained on the examples below :

What is Abstract Factory design pattern ?

According to GoF’s definition, this pattern is :

Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

This pattern is generally referred to as super-set of the factory pattern.

Since it is a broader or super set of the Factory pattern, we will try to discuss this with an example of the Factory Pattern and try to move on to the Abstract factory. So let’s start with the Factory pattern example :

A real world example for Factory pattern :

Suppose, your company gets a assignment in .NET technologies. You have a team of 20 members in .NET, with one team of Silverlight and other of DotNet. Your business development team says, give us the team of members with a required skillset. So your manager receives the required skill set from the BD team, selects a team from the two and gives them the assignment. So here,

BD team acts as the client who requests for a team to work on a project.

Your manager acts the Factory, who will decide the team to be selected.

Silverlight & DotNet teams are one of the final outputs/resources received by the client or the BD team to work on the project.

So our factory structure will be something like the below :

And our BD team or client will be sending the request as :

Run the code and see the results.

So this was the Factory pattern, where you have a single requirement (or a single product to be more precise, in terms of the definition of this pattern)

So now the need arises where your company receive a new project which requires two different teams one of .NET and other of mobile technologies(could be Windows or could be Android based), to work on another project.

So here we have more options to achieve this requirement :

Option One :

Add another method, to the same factory we created above, to get the team for the mobile technologies. So our code becomes :

But this will not be a good approach. This is because, we have added one more functionality, we should be making it more abstract, as we may get another project in future, which may want to have its own criteria of selecting any team or which may add another requirement like a JAVA team to be included.

Option Two :

We create another factory like the one we created for the .NET and then get the required team from the Mobile technologies team. But this is also not a good approach, as this may result in more and more factories as the requirements of adding more and more teams arises. Also the same reason above, we may have more projects in future, which may also need the selection of a mobile and .net technology team to work on.

The concept that we have discussed till now, gives us the following points :

We may have more requirements in future (i.e. May need third type of team like Java or any other technology team), for another projects.So we may be required to create another factory and may increase further in number, as more requirements are added.

Right now, we have only one project and based on it we send the requirements and get the required output. But another project, may have different requirements. That project may have its own way of deciding that what are the basic criteria of selecting the required team.

So, these are the two main points, which are addressed by the Abstract Factory pattern. Let’s see, how we can do this with the technically through the code and then we will discuss the above two points, handled by our code.

So our first job will be to create a Base Factory, which will be encapsulating the definition of the factories (or Team deciding factories)

Now comes the main point of discussion. We will be creating 2 different factories which will implementing the base factory, in their own ways . These factories are nothing but the Projects that we receive. So both these projects will be deciding their requirements for getting the two different teams, in their own way. This is nothing but the point 2 that we discussed above

So our code becomes the following for two different projects

and for project two :

As we can see, we have no specific requirements for selecting the teams for project 2. Both these projects provide their own implementations.

Finally, further class implementations will remain the same like the below :

Now the BD team will be getting the requirements as :

Now, run the code and see the results :

Let’s discuss how the above code covers the two points that we covered earlier.

This first point we discussed above, for the more technology teams getting added, We have the same requirement getting addressed by the use of a common base interface IBaseFactory. So we can add more teams whenever required, in the base factory (like we added the IMobileTechnologiesTeamFactory team).

The second point we discussed was regarding different requirements of different projects. So class ProjectOne specifies its own requirements for the teams required and class ProjectTwo, does not has any specific requirements. So both have their own definitions.

These are, what i feel, the reason for use of this design pattern and what i have got the understanding of this pattern from my study. One last point, remember the definition that i mentioned in the start of the article :

“Results in an, interface which provides families of related or dependent objects without providing their concrete classes.”

This is also in sync with the example we discussed, as we have the interface IBaseFactory,with groups related functionality into a single unit.

Any more suggestion/point you would like to add to this article are welcome.