The abstract factory is one of the Gang of Four creational patterns and as the name implies it is concerned with the abstraction of creating. The factory part of this pattern can be very useful if an object is created in many places throughout your code. It helps you to centralise its initialisation giving you a nice separation of concerns, the code that consumes the object is insulated from the code that creates the object. On the other hand the abstract part is just as useful, the factory returns a contract rather than a concrete type. The consumer of the factory only knows about the contract and there for you can swap in and out implementations (even at runtime) with little effort.

It has been pointed out to me in the past that you do have to be careful when using this pattern, and I agree with this reservation. It can be pointless work if the usage scope of the object is small, a private class is a good example of possible overuse of an abstract factory.

I have created an example project where a bar person makes a person’s favourite drinks.

There are three people:

Mr Bond Loves a Shaken Martini

Scott Loves a Coffee Martini

I love a Stirred Martini

Scott, Mr Bond, and myself are the factories and the bar person is the client who uses those factories.

The BarPerson asks what the factories favourite drink is, and the factory returns an instance of that IDrink. There are unit tests included to verify that the correct drink was returned by the BarPerson.