Little Computer People

Question: What is an abstract factory?
Answer: A factory for factories.

It is as simple as that.
Guess, you have a family of objects. To get instances from each of the objects, you have to call the appropriate factory.
The disadvantage is obvious: you have to deal with a lot of factories.

So, at this point, the abstract factory comes in to play.
You know, you need some kind of an object, let’s say a connection to a database:
So instead, of straying around in the jungle of factories, you take only one factory, which to tell, what fatory you are looking for, and: There you are!

A simplified Version looks like this:

DbProviderFactory factory = DbProviderFactories.GetFactory("System.Data.SqlClient");

http://msdn.microsoft.com/en-us/library/system.data.common.dbproviderfactory.aspx

Is an example of an abstract factory.
Here it is used to retrieve a factory for connections.

Today I found a really nice Picture:

https://plus.google.com/u/0/117665613028757061169/posts

The Picture is a little bit controversial.
On the one hand you have something like massmedia-Facebook and on the other hand you have something like elitist google+.

I won’t and could not take part of this controversy, since I have no facebook account (or to paraphrase Mario Sixtus »I would like to complain about facebook, but that makes me standing with all the other sissies in the corner«).

But there is really one point. It is the point that indeed my usage of google+ is more like reading a feuilleton than chitchatting jibberjabber with my next-door-neighbour. The accounts, which i am following reflect this best. Okay, at first, I added friends and acqauints to start off with, but now I am more and more following creative minds (i would like to call them); creative people who inspire me, make me laugh and think about the world in new ways.

The factory pattern is the most and widely used pattern in the wild.

It can come as simple as this:

public class Factory
{
	public static Product GetInstance()
	{
		return new Product();
	}
}

Or maybe you have an Interface, where you defined what methods your Factory should provide:

public class Factory: IFactory
{
	public static Product GetInstance()
	{
		return new Product();
	}
}

If you take a look into literature, you will find it modeled in UML like the following

You have an (abstract) baseclass from which you (have to) derive your concrete factory.
And the factory itself produces the (concrete) product.

The main advantage of using a factory instead of simply newing your object is, that you seperate the consumption of objects from its production.

Think of code like this:

...
 
ILogger logger = LoggerFactory.GetInstance();
 
...

With code like this, you make clear, what your intent is:
»I want to have something, that does logging for me.«
As long as that, what you got goes conform with ILogging, you know it does its job.
You are at this point in code not interested, what the hell is needed, to wire up the Logger, or something like that.
You say, what you want.
You get, what you want.
And wherever you want (YippieYeah! thank god, it’s static).

The factory is the first and simplest pattern to use, which helps to keep your code tidy and prevents clutter.