Factory design pattern Vs abstract factory design pattern

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

> 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

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

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.

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.