What is the basic difference between the Factory and Abstract Factory Patterns?
19 Answers
426
votes
With the Factory pattern, you produce instances of implementations (Apple, Banana, Cherry, etc.) of a particular interface -- say, IFruit.
With the Abstract Factory pattern, you provide a way for anyone to provide their own factory. This allows your warehouse to be either an IFruitFactory or an IJuiceFactory, without requiring your warehouse to know anything about fruits or juices.
148
votes
Source for this information taken from: http://java.dzone.com/news/intro-design-patterns-abstract
Abstract Factory vs. Factory Method
The methods of an Abstract Factory are implemented as Factory Methods. Both the Abstract Factory Pattern and the Factory Method Pattern decouples the client system from the actual implementation classes through the abstract types and factories. The Factory Method creates objects through inheritance where the Abstract Factory creates objects through composition.
The Abstract Factory Pattern consists of an AbstractFactory, ConcreteFactory, AbstractProduct, ConcreteProduct and Client.
How to implement
The Abstract Factory Pattern can be implemented using the Factory Method Pattern, Prototype Pattern or the Singleton Pattern. The ConcreteFactory object can be implemented as a Singleton as only one instance of the ConcreteFactory object is needed.
Factory Method pattern is a simplified version of Abstract Factory pattern. Factory Method pattern is responsible for creating products that belong to one family, while Abstract Factory pattern deals with multiple families of products.
Factory Method uses interfaces and abstract classes to decouple the client from the generator class and the resulting products. Abstract Factory has a generator that is a container for several factory methods, along with interfaces decoupling the client from the generator and the products.
When to Use the Factory Method Pattern
Use the Factory Method pattern when there is a need to decouple a client from a particular product that it uses. Use the Factory Method to relieve a client of responsibility for creating and configuring instances of a product.
When to Use the Abstract Factory Pattern
Use the Abstract Factory pattern when clients must be decoupled from product classes. Especially useful for program configuration and modification. The Abstract Factory pattern can also enforce constraints about which classes must be used with others. It may be a lot of work to make new concrete factories.
Examples:
Abstract Factory Example 1
This specification for the disks to prepare different types of pasta in a pasta maker is the Abstract Factory, and each specific disk is a Factory. all Factories (pasta maker disks) inherit their properties from the abstract Factory. Each individual disk contains the information of how to create the pasta, and the pasta maker does not.
Abstract Factory Example 2:
The Stamping Equipment corresponds to the Abstract Factory, as it is an interface for operations that create abstract product objects. The dies correspond to the Concrete Factory, as they create a concrete product. Each part category (Hood, Door, etc.) corresponds to the abstract product. Specific parts (i.e., driver side door for 99 camry) corresponds to the concrete products.
Factory Method Example:
The toy company corresponds to the Creator, since it may use the factory to create product objects. The division of the toy company that manufactures a specific type of toy (horse or car) corresponds to the ConcreteCreator.
101
votes
Factory pattern: The factory produces IProduct-implementations
Abstract Factory Pattern: A factory-factory produces IFactories, which in turn produces IProducts :)
[Update according to the comments]
What I wrote earlier is not correct according to Wikipedia at least. An abstract factory is simply a factory interface. With it, you can switch your factories at runtime, to allow different factories in different contexts. Examples could be different factories for different OS'es, SQL providers, middleware-drivers etc..
43
votes
The Abstract Factory Pattern
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
The Abstract Factory pattern is very similar to the Factory Method pattern. One difference between the two is that with the Abstract Factory pattern, a class delegates the responsibility of object instantiation to another object via composition whereas the Factory Method pattern uses inheritance and relies on a subclass to handle the desired object instantiation.
Actually, the delegated object frequently uses factory methods to perform the instantiation!
Factory pattern
Factory patterns are examples of creational patterns
Creational patterns abstract the object instantiation process. They hide how objects are created and help make the overall system independent of how its objects are created and composed.
Class creational patterns focus on the use of inheritance to decide the object to be instantiated Factory Method
Object creational patterns focus on the delegation of the instantiation to another object Abstract Factory
Reference: Factory vs Abstract Factory
39
votes
Factory method: You have a factory that creates objects that derive from a particular base class
Abstract factory: You have a factory that creates other factories, and these factories in turn create objects derived from base classes. You do this because you often don't just want to create a single object (as with Factory method) - rather, you want to create a collection of related objects.
39
votes
Basic difference:
Factory: Creates objects without exposing the instantiation logic to the client.
Factory Method: Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory method lets a class defer instantiation to subclasses
Abstract Factory: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
AbstractFactory pattern uses composition to delegate responsibility of creating object to another class while Factory method pattern uses inheritance and relies on derived class or sub class to create object
From oodesign articles:
Factory class diagram:
Example: StaticFactory
public class ShapeFactory {
//use getShape method to get object of type shape
public static Shape getShape(String shapeType){
if(shapeType == null){
return null;
}
if(shapeType.equalsIgnoreCase("CIRCLE")){
return new Circle();
} else if(shapeType.equalsIgnoreCase("RECTANGLE")){
return new Rectangle();
} else if(shapeType.equalsIgnoreCase("SQUARE")){
return new Square();
}
return null;
}
}
Non-Static Factory implementing FactoryMethod example is available in this post:
Design Patterns: Factory vs Factory method vs Abstract Factory
When to use: Client just need a class and does not care about which concrete implementation it is getting.
Factory Method class digaram:
When to use: Client doesn't know what concrete classes it will be required to create at runtime, but just wants to get a class that will do the job.
Abstract Factory class diagram from dzone
When to use: When your system has to create multiple families of products or you want to provide a library of products without exposing the implementation details.
Source code examples in above articles are very good to understand the concepts clearly.
Related SE question with code example:
Factory Pattern. When to use factory methods?
Differences:
- Abstract Factory classes are often implemented with Factory Methods, but they can also be implemented using Prototype
- Designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward other creational patterns (more flexible, more complex) where more flexibility is needed.
- Factory Methods are usually called within Template Methods.
Other useful articles:
factory_method from sourcemaking
abstract_factory from sourcemaking
abstract-factory-design-pattern from journaldev
36
votes
23
votes
Example/Scenario for Abstract Factory
I live in a place where it rains in the rainy season, snows in winter and hot and sunny in summers. I need different kind of clothes to protect myself from the elements. To do so I go to the store near my house and ask for clothing/items to protect myself. The store keeper gives me the appropriate item as per the environment and depth of my pocket. The items he gives me are of same level of quality and price range. Since he is aware of my standards its easy for him to do so. But when a rich guy from across the street comes up with the same requirements he gets an expensive, branded item. One noticeable thing is all the items he gives to me complement each other in term quality, standard and cost. One can say they go with each other. Same is the case with the items this rich guy gets.
So by looking at above scenario, I now appreciate the efficiency of the shop keeper. I can replace this shopkeeper with an Abstract Shop. The items we get with abstract items and me and the rich as perspective clients. All we need is the product/item which suits our needs.
Now I can easily see myself considering an online store which provides a set of services to its numerous clients. Each client belongs to one of the three groups. When a premium group user opens up the site he gets great UI, highly customised advertisement pane, more options in the menus etc. These same set of features are presented to gold user but the functionality in the menu is less, advertisements are mostly relevent, and slightly less egronomic UI. Last is my kind of user, a ‘free group’ user. I am just served enough so that I do not get offended. The UI is a bare minimum, advertisements are way off track so much so that I do not know what comes in it, lastly the menu has only log out.
If I get a chance to build something like this website I would definitely consider Abstract Factory Pattern.
Abstract Products : Advertisement Pane, Menu, UI painter.
Abstract Factory : Web Store User Experience
Concreate Factory: Premium User Experience, Gold User Experience, General User Experience.
22
votes
Many people will feel surprised maybe, but this question is incorrect. If you hear this question during an interview, you need to help the interviewer understand where the confusion is.
Let's start from the fact that there is no concrete pattern that is called just "Factory". There is pattern that is called "Abstract Factory", and there is pattern that is called "Factory Method".
So, what does "Factory" mean then? one of the following (all can be considered correct, depending on the scope of the reference):
- Some people use it as an alias (shortcut) for "Abstract Factory".
- Some people use it as an alias (shortcut) for "Factory Method".
- Some people use it as a more general name for all factory/creational patterns. E.g. both "Abstract Factory" and "Factory Method" are Factories.
And, unfortunately, many people use "Factory" to denote another kind of factory, that creates factory or factories (or their interfaces). Based on their theory:
Product implements IProduct, which is created by Factory, which implements IFactory, which is created by AbstractFactory.
To understand how silly this is, let's continue our equation:
AbstractFactory implements IAbstractFactory, which is created by... AbstractAbstractFactory???
I hope you see the point. Don't get confused, and please don't invent things that don't exist for reason.
-
P.S.: Factory for Products is AbstractFactory, and Factory for Abstract Factories would be just another example of AbstractFactory as well.
16
votes
//Abstract factory - Provides interface to create factory of related products
interface PizzaIngredientsFactory{
public Dough createDough(); //Will return you family of Dough
public Clam createClam(); //Will return you family of Clam
public Sauce createSauce(); //Will return you family of Sauce
}
class NYPizzaIngredientsFactory implements PizzaIngredientsFactory{
@Override
public Dough createDough(){
//create the concrete dough instance that NY uses
return doughInstance;
}
//override other methods
}
The text book definitions are already provided by other answers. I thought I would provide an example of it too.
So here the PizzaIngredientsFactory is an abstract factory as it provides methods to create family of related products.
Note that each method in the Abstract factory is an Factory method in itself. Like createDough() is in itself a factory method whose concrete implementations will be provided by subclasses like NYPizzaIngredientsFactory. So using this each different location can create instances of concrete ingredients that belong to their location.
Factory Method
Provides instance of concrete implementation
In the example:
- createDough() - provides concrete implementation for dough. So this is a factory method
Abstract Factory
Provides interface to create family of related objects
In the example:
- PizzaIngredientsFactory is an abstract factory as it allows to create a related set of objects like Dough, Clams, Sauce. For creating each family of objects it provides a factory method.
Example from Head First design patterns
5
votes
I have some points to contribute with John's answer as follows:
Abstract factory is a factory of factories!
With the "Factory Method" (because just "Factory" is ambiguous), you produce implementations (Lemon, Orange, etc.) of a particular interface -- say, IFruit. This Factory could be called CitricFruitFactory.
But now you want to create another kinds of fruit that the CitricFruitFactory is not able to create. Maybe the code of CitricFruitFactory wouldn't make sense if you create an Strawberry in it (strawberry is not a citric fruit!).
So you could create a new Factory called RedFruitFactory that produces Strawberry, Raspberry, etc.
Like John Feminella said:
"With the Abstract Factory pattern, you produce implementations of a particular Factory interface -- e.g., IFruitFactory. Each of those knows how to create different kinds of fruit."
That implementatios of IFruitFactory are CitricFruitFactory and RedFruitFactory!
4
votes
My sources are : StackOverflow, tutorialspoint.com, programmers.stackexchange.com and CodeProject.com.
Factory Method (also called Factory) is for decouple client of a Interface implementation. For sample we have a Shape interface with two Circle and Square implementations. We have define a factory class with a factory method with a determiner parameter such as Type and new related implementation of Shape interface.
Abstract Factory contains several factory method or a factory interface by several factory implementations.
For next above sample we have a Color interface with two Red and Yellow implementations.
We have define a ShapeColorFactory interface with two RedCircleFactory and YellowSquareFactory. Following code for explain this concept:
interface ShapeColorFactory
{
public Shape getShape();
public Color getColor();
}
class RedCircleFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Circle();
}
@Override
public Color getColor() {
return new Red();
}
}
class YellowSquareFactory implements ShapeColorFactory
{
@Override
public Shape getShape() {
return new Square();
}
@Override
public Color getColor() {
return new Yellow();
}
}
Here difference between FactoryMethod and AbstractFactory. Factory Method as simply return a concrete class of a interface but Abstract Factory return factory of factory. In other words Abstract Factory return different combine of a series of interface.
I hope my explanation useful.
3
votes
The major difference in those factories is when what you want to do with the factories and when you want to use it.
Sometimes, when you are doing IOC (inversion of control e.g. constructor injection), you know that you can create solid objects. As mentioned in the example above of fruits, if you are ready to create objects of fruits, you can use simple factory pattern.
But many times, you do not want to create solid objects, they will come later in the program flow. But the configuration tells you the what kind of factory you want to use at start, instead of creating objects, you can pass on factories which are derived from a common factory class to the constructor in IOC.
So, I think its also about the object lifetime and creation.
3
votes
Both Factory Method and Abstract Factory keep the clients decoupled from the concrete types. Both create objects, but Factory method uses inheritance whereas Abstract Factory use composition.
The Factory Method is inherited in subclasses to create the concrete objects(products) whereas Abstract Factory provide interface for creating the family of related products and subclass of these interface define how to create related products.
Then these subclasses when instantiated is passed into product classes where it is used as abstract type. The related products in an Abstract Factory are often implemented using Factory Method.
3
votes
Extending John Feminella answer:
Apple, Banana, Cherry implements FruitFactory and that has a method called Create which is solely responsible of creating Apple or Banana or Cherry. You're done, with your Factory method.
Now, you want to Create a special salad out of your fruits and there comes your Abstract Factory. Abstract Factory knows how to create your special Salad out of the Apple, Banana and Cherry.
public class Apple implements Fruit, FruitFactory {
public Fruit Create() {
// Apple creation logic goes here
}
}
public class Banana implements Fruit, FruitFactory {
public Fruit Create() {
// Banana creation logic goes here
}
}
public class Cherry implements Fruit, FruitFactory {
public Fruit Create() {
// Cherry creation logic goes here
}
}
public class SpecialSalad implements Salad, SaladFactory {
public static Salad Create(FruitFactory[] fruits) {
// loop through the factory and create the fruits.
// then you're ready to cut and slice your fruits
// to create your special salad.
}
}
2
votes
By Definition we can drag out the differences of two:
Factory: An interface is used for creating an object, but subclass decides which class to instantiate. The creation of object is done when it is required.
Abstract Factory: Abstract Factory pattern acts as a super-factory which creates other factories. In Abstract Factory pattern an interface is responsible for creating a set of related objects, or dependent objects without specifying their concrete classes.
So, in the definitions above we can emphasize on a particular difference. that is, Factory pattern is responsible for creating objects and Abstract Factory is responsible for creating a set of related objects; obviously both through an interface.
Factory pattern:
public interface IFactory{
void VehicleType(string n);
}
public class Scooter : IFactory{
public void VehicleType(string n){
Console.WriteLine("Vehicle type: " + n);
}
}
public class Bike : IFactory{
public void VehicleType(string n) {
Console.WriteLine("Vehicle type: " + n);
}
}
public interface IVehicleFactory{
IFactory GetVehicleType(string Vehicle);
}
public class ConcreteVehicleFactory : IVehicleFactory{
public IFactory GetVehicleType(string Vehicle){
switch (Vehicle){
case "Scooter":
return new Scooter();
case "Bike":
return new Bike();
default:
return new Scooter();
}
}
class Program{
static void Main(string[] args){
IVehicleFactory factory = new ConcreteVehicleFactory();
IFactory scooter = factory.GetVehicleType("Scooter");
scooter.VehicleType("Scooter");
IFactory bike = factory.GetVehicleType("Bike");
bike.VehicleType("Bike");
Console.ReadKey();
}
}
Abstract Factory Pattern:
interface IVehicleFactory{
IBike GetBike();
IScooter GetScooter();
}
class HondaFactory : IVehicleFactory{
public IBike GetBike(){
return new FZS();
}
public IScooter GetScooter(){
return new FZscooter();
}
}
class HeroFactory: IVehicleFactory{
public IBike GetBike(){
return new Pulsur();
}
public IScooter GetScooter(){
return new PulsurScooter();
}
}
interface IBike
{
string Name();
}
interface IScooter
{
string Name();
}
class FZS:IBike{
public string Name(){
return "FZS";
}
}
class Pulsur:IBike{
public string Name(){
return "Pulsur";
}
}
class FZscooter:IScooter {
public string Name(){
return "FZscooter";
}
}
class PulsurScooter:IScooter{
public string Name(){
return "PulsurScooter";
}
}
enum MANUFACTURERS
{
HONDA,
HERO
}
class VehicleTypeCheck{
IBike bike;
IScooter scooter;
IVehicleFactory factory;
MANUFACTURERS manu;
public VehicleTypeCheck(MANUFACTURERS m){
manu = m;
}
public void CheckProducts()
{
switch (manu){
case MANUFACTURERS.HONDA:
factory = new HondaFactory();
break;
case MANUFACTURERS.HERO:
factory = new HeroFactory();
break;
}
Console.WriteLine("Bike: " + factory.GetBike().Name() + "\nScooter: " + factory.GetScooter().Name());
}
}
class Program
{
static void Main(string[] args)
{
VehicleTypeCheck chk = new VehicleTypeCheck(MANUFACTURERS.HONDA);
chk.CheckProducts();
chk= new VehicleTypeCheck(MANUFACTURERS.HERO);
chk.CheckProducts();
Console.Read();
}
}
1
votes
Check here: http://www.allapplabs.com/java_design_patterns/abstract_factory_pattern.htm it seems that Factory method uses a particular class(not abstract) as a base class while Abstract factory uses an abstract class for this. Also if using an interface instead of abstract class the result will be a different implementation of Abstract Factory pattern.
:D
1
votes
Abstract Factory is template for creating different type of interfaces. Suppose you have project that requires you to parse different types of csv files containing quantity, price and item specific information like some contain data about fruits other about chocolates and then after parsing you need to update this information in their corresponding database so now you can have one abstract factory returning you parser and modifier factory and then this parser factory can return you Chocolate parser object,Fruit Parser Object etc. and similarly Modifier Factory can return Chocolate modifier object , Fruit Modifier object etc.
1
votes
I think we can understand the difference between these two by seeing a Java8 example code:
interface Something{}
interface OneWhoCanProvideSomething {
Something getSomething();
}
interface OneWhoCanProvideCreatorsOfSomething{
OneWhoCanProvideSomething getCreator();
}
public class AbstractFactoryExample {
public static void main(String[] args) {
//I need something
//Let's create one
Something something = new Something() {};
//Or ask someone (FACTORY pattern)
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeA = () -> null;
OneWhoCanProvideSomething oneWhoCanProvideSomethingOfTypeB = () -> null;
//Or ask someone who knows soemone who can create something (ABSTRACT FACTORY pattern)
OneWhoCanProvideCreatorsOfSomething oneWhoCanProvideCreatorsOfSomething = () -> null;
//Same thing, but you don't need to write you own interfaces
Supplier<Something> supplierOfSomething = () -> null;
Supplier<Supplier<Something>> supplierOfSupplier = () -> null;
}
}
Now the question is which way of creation should you use and why: The first way (no pattern, just plain constructor): creating by yourself is not a good idea, you have to do all the work, and your client code is tied to the particular implementation.
The second way (using Factory pattern): provides you the benefit that you can pass any type of implementation, which can provide different type of something based on some condition (maybe a parameter passed to creational method).
The third way (using Abstract Factory pattern): This gives you more flexibility. You can find different types of creators of something based on some condition (maybe a parameter passed).
Note that you can always get away with Factory pattern by combining two conditions together (which slightly increases code complexity, and coupling), I guess that's why we rarely see real life use cases of Abstract Factory pattern.
createThing()) and Abstract Factory uses composition (indirection is horizontal e.g.getFactory().createThing()) – David James