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.