Why do we need Abstract factory design pattern ???

Question

Most of the definition says:

An abstract factory provides an interface for creating families of related objects without specifying their concrete classes

What is the use of Abstract Factory Pattern as we can achieve the task via creating object of concrete class itself. Why do we have a factory method that creates object of Concrete class?

Please provide me any real life example where I must implement abstractFactory pattern?

Answer 1

If you look at the design patterns, almost all of them can be made redundant. But what pattern means a commonly used approach for a solution to a similar type of problems. A design pattern provides you a design level approach or solution to a set of similar type of design problem. Using design pattern help you solve your problem and hence deliver faster.

Answer 2

If I understand you right - the question is, why do we have both the Factory method and the abstract factory patterns. You need abstract factory when different polymorphic classes has different instantiation procedure. And you want some module to create instances and use them, without knowing any details of object initialization. For example - you want to create Java objects doing some calculations. But some of them are part of the application, while other's bytecode should be read from the DB. In the other hand - why do we need factory method? Agree, that abstract factory overlaps it. But in some cases - it is much less code to write, having less classes and interfaces makes system easier to comprehend.

Answer 3

Abstract Factory is a very central design pattern for Dependency Injection (DI). Here's a list of Stack Overflow questions where application of Abstract Factory has been accepted as the solution.

To the best of my understanding, these questions represent real concerns or problems that people had, so that should get you started with some real-life examples:

• http://stackoverflow.com/questions/1943576/is-there-a-pattern-for-initializing-objects-created-wth-a-di-container/1945023#1945023
• http://stackoverflow.com/questions/1926826/cant-combine-factory-di/1927167#1927167
• http://stackoverflow.com/questions/2168704/wcf-dependency-injection-and-abstract-factory/2168882#2168882
• http://stackoverflow.com/questions/1890341/how-to-set-up-ioc-when-a-key-class-needs-session-or-other-context-specific-varia/1890463#1890463
• http://stackoverflow.com/questions/2180276/how-to-resolve-type-based-on-end-user-configuration-value/2182775#2182775
• http://stackoverflow.com/questions/1706056/strategy-pattern-and-dependency-injection-using-unity/1706352#1706352
• http://stackoverflow.com/questions/1993397/abstract-factory-pattern-on-top-of-ioc/1994455#1994455
• http://stackoverflow.com/questions/1892532/is-this-the-correct-way-to-use-and-test-a-class-that-makes-use-of-the-factory-pat/1892636#1892636
• http://stackoverflow.com/questions/2194629/ddd-book-eric-evans-please-explain-what-is-meant-by-the-factory-should-be-abst/2198504#2198504
• http://stackoverflow.com/questions/2060767/di-container-factory-or-new-for-ephemeral-objects/2060840#2060840
• http://stackoverflow.com/questions/1900358/how-to-unit-test-instance-creation/1900446#1900446
• http://stackoverflow.com/questions/1682925/what-is-the-best-strategy-for-dependency-injection-of-user-input/1686403#1686403

Answer 4

A real life example for the use of the Abstract Factory pattern is providing data access to two different data sources (e.g. a SQL Database and a XML file). You have two different data access classes (a gateway to the datastore). Both inherit from a base class that defines the common methods to be implemented (e.g. Load, Save, Delete).

Which data source shall be used shouldn't change the way client code retrieves it's data access class. Your Abstract Factory knows which data source shall be used and returns an appropriate instance on request. The factory returns this instance as the base class type.

Answer 5

it easy, imaging that you have a code that works with the abstraction, you should create abstractions and not concrete classes.

You should always work against abstractions because you can modify the code better.

This is a good example: http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.23

Answer 6

I find the Abstract Factory pattern overrated.

First of all, it doesn't happen that often that you have a set of interrelated types you want to instantiate.

Secondly, the level of indirection (abstraction) provided by interfaces normally suffices when working with dependency injection.

The typical example of WindowsGui vs MacGui vs ... where you'd have a WindowsButton, MacButton, WindowsScrollBar, MacScrollbar, etc. is often easier to implement by defining concrete Buttons, Scrollbars, etc. using Visitor and/or Interpreter pattern to provide actual behaviour.

Answer 7

To answer directly your question, you can probably get away without using such a design pattern.

However bear in mind, that most of projects in the real-world evolve and you want to provide some kind of extensibility in order to make your project future-proof.

From my own experience, most of the time, a Factory is implemented and as the project grows it gets changed into more complex design patterns such as an Abstract Factory.