Factory design pattern Vs abstract factory design pattern

[Nimmi Srivastav]

Hi,

Can anyone kindly help me to understand, once and for all, the
difference between the Factory design pattern and the Abstract Factory
design pattern, as discussed in the GoF book.

Are there enough differences between the two to warrant including both
of them as separate patterns altogether.

Regards,
Nimmi

[Klaus Horsten]

> Can anyone kindly help me to understand, once and for all, the
> difference between the Factory design pattern and the Abstract Factory
> design pattern.

There is an objective reason for this uncertainty:

The examples you find for them for example in C# are very bad because
they are not taken out of a real project.

I can use the factory method for example to replace a switch statement
when I refactor. I have not yet encountered a situation to use an
abstract factory pattern.

The danger here is overengineering.

There is a quite good explanation at
http://jamesthornton.com/eckel/TIPat...Chapter06.html

Klaus

[Pradyumn Sharma]

nimmi_srivastav@yahoo.com (Nimmi Srivastav) wrote in message news:<8b0c42d.0310230728.252a4ffe@posting.google.com>...
> Hi,
>
> Can anyone kindly help me to understand, once and for all, the
> difference between the Factory design pattern and the Abstract Factory
> design pattern, as discussed in the GoF book.
>
> Are there enough differences between the two to warrant including both
> of them as separate patterns altogether.
>
> Regards,
> Nimmi

If there is only one creator, it specifies an abstract factory method,
allowing its subclasses to choose the concrete product to instantiate.

interface Product {
// ...
}

class Product1 implements Product {
// ...
}

abstract class Creator {
someMethod () {
// ...
Product prod = createProduct ();
// ...
}
abstract Product createProduct ();
// ...
}

class Creator1 extends Creator {
Product createProduct () {
return new Product1 ();
}
// ...
}

However, if there are multiple creators in the application, which want
to create these products, we may end up duplicating these factory
methods in all of them. For example:

abstract class someOtherCreator {
someOtherMethod () {
// ...
Product prod = createProduct ();
// ...
}
abstract Product createProduct ();
// ...
}

class someOtherCreator1 extends someOtherCreator {
Product createProduct () {
return new Product1 ();
}
// ...
}

We can avoid this duplication of the factory methods in two (or more)
creator hierarchies, by factoring out these factory methods in a
separate class.

abstract class Factory {
public abstract Product createProduct ();
}

class Factory1 extends Factory {
public Product createProduct () {
return new Product1 ();
}
}

class Creator {
private Factory factory;
public Creator (Factory f) {
factory = f;
}
someMethod () {
// ...
Product prod = factory.createProduct ();
// ...
}
// ...
}

class someOtherCreator {
// ... calling factory.createProduct, like in Creator class above.
}

Hope this helps.

Pradyumn Sharma
www.pragatisoftware.com

[Jeff Grigg]

nimmi_srivastav@yahoo.com (Nimmi Srivastav) wrote...
> Can anyone kindly help me to understand, once and for all, the
> difference between the Factory design pattern and the Abstract Factory
> design pattern, as discussed in the GoF book.

The "Factory Method" pattern is a method on a class, used to build
other instances. You can implement a Factory Method on just about any
class that happens to be handy at the time.

The "Abstract Factory" pattern is about creating a class that has
nothing (of interest) other than Factory Method(s) on it. Use this
when you need to create a suite of different but matching objects, or
if the act of controlling object creation rises to the point of being
the primary function of the class.


> Are there enough differences between the two to warrant including both
> of them as separate patterns altogether.

"Should" they be separate? Well, that's entirely a matter of
subjective opinion. Personally, I tend to see them as two
implementations of the same pattern, but I could be convinced
otherwise. Don't expect the Design Patterns book to be the do-all
end-all perfect example of *THE* correct patterns. I think, for
example, that the Null Object pattern is a glaring omission of the
original book. But that's OK; there are thousands of other
interesting and relevant patterns that were also not included in the
original book. Read other books and web sites. There's a lot to
learn.

[Malte Persike]

On 25 Oct 2003 06:45:53 -0700, jgrigg@mo.net (Jeff Grigg) wrote:

>"Should" they be separate? Well, that's entirely a matter of
>subjective opinion. Personally, I tend to see them as two
>implementations of the same pattern, but I could be convinced
>otherwise.


There is a difference in the flexibility of the relationship between
the creation of objects (the factory) and the object requesting that
creation.

With factory methods you introduce a determination between a concrete
class and the products it will receive from the factory. A concrete
class X will be limited to receiving products A1, A2, A3. If you
wanted to alter the products, you had to instantiate a different
concrete class Y, even if Y looked exactly like class X except for the
implementation of the factory methods.

The abstract factory loosens this coupling. If logic and
implementation of a system do not change when products vary, the
abstract factory is the pattern of choice.

Take, for example, the GUI in Windows XP (sorry, first thing that came
to my mind). I suppose that microsoft implemented the switching
between the traditional look of the controls and the bubblegum Luna
interface with some variant of abstract factory. System and
applications do not change in behavior (i. e. implementation), its
look does.

Whether factory method and abstract factory are seperate or not can
still be argued upon but I generally think of them as seperate
patterns. The GoF book states that "Abstract Factory (87) is often
implemented with factory methods". This at least shows that the
assumption of an "Is a" relationship might be dropped in favour of a
"Has a" connection.

Regards,
Malte

---

The above e-mail address is not valid. To
contact me, please use my real e-mail address:

malte AT t DASH online DOT de

Just replace the capitalized words with the
corresponding punctuation marks.

[amol_thikane]

Abstract Factory - Provide an interface for creating families of related or dependent objects without specifying their concrete classes.[Ref : GoF]
Factory method - Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses. [Ref :GoF]

Example :
We have class Shop(LaptopShoppy) where we can able to purchase different Laptops manufactured by HP(HPLaptop), Dell(DellLaptop), Inspiron(InspironLaptop) which are basically certain configuration('Laptop' base class for HPLaptop and..).
Every manufacturer has their own vendor factory in different continent (Continent base class) like Asia (AsiaFactory), Europe (EuropeFactory), America (AmericaFactory).
So Asia factory vendor might create Processor for HP (HPProcessor), Dell (DellProcessor) or Inspiron (InspironProcessor). And Europe factory vendor might create RAM for HP(HPRAM), Dell (DellRAM) or Inspiron (InspironRAM).
So Customer visits Laptop shop and ask for HP/Dell/Inspiron laptop then there manufacturer asks Asia, Europe and America vendor to create laptop for them and supply the laptop.

1. Abstract factory - Thinking in shop perspective they have laptop from different manufacturer i.e. creating family of related objects.

2. Factory Method - Thinking in vendor perspective they can create Processor or RAM as per customer's demand like HP require this technology but Dell has another technology requirement i.e. HP/Dell/Inspiron don't bother from how their product is get created but they will get what they asked.

I think this give a good idea about Abstract factory and Factory Method DP.

[sofiarunner]

I would like to describe more about factory method. Factory Method is a object-oriented design pattern and deals with the programing method . It provides an abstraction or an interface and lets subclass or implementing classes decide.