Design Patterns discussion

["Mikal Ziane" <Mikal.Ziane AT lip6.fr>]

Prabodh,

I wonder if your are not confusing the problem addressed by Factory Method
with the problem addressed by Builder.
Factory Method does allow you to decouple the code creating instances  of a
Product interfaces from the classes implementing this interface BUT this is
useful even if you do not assemble Product objects together.
The mechanism used by Factory Method is the following :
  occurrences of « new ConcreteProduct(...) ; » are folded i.e. replaced by
calls to a method, here the factory method.
This mechanism is identical to that of Prototype when Prototype is used to
solve the same problem (the folding method is clone() then).
The only difference is that in Prototype the factory method is attached to
the Product interface itself.
When the solution of Prototype is not possible (e. g. the Product interface
cannot be changed and there is no clone method) the factory method must be
attached to another hierarchy, parallel to that of Product : this is the
solution of Factory Method.

So your question as I understood it is « are there reasons to do something
even more complex than Factory Method » while I would rather try to avoid
the complexity of Factory Method if the parallel hierarchy is not already
present.
I suspect that your question is more related to the Builder pattern : are
there cases where separating several levels of abtraction in builders can be
useful.


-----Message d'origine-----
De : 
gang-of-4-patterns-admin AT cs.uiuc.edu
[mailto:gang-of-4-patterns-admin AT cs.uiuc.edu]
 
Envoyé : mardi 18 novembre 2003 08:20
À : 
gang-of-4-patterns AT cs.uiuc.edu
Objet : [gang-of-4-patterns] Factory Method and Loosely Coupled Code

The point of discussion is
~~~~~~~~~~~~~~~~~~~~~~~~~~
How does Factory Method promote loosely coupled code? 

Following are some points coming to my mind. Please add to it.


1. Factory Method pattern provides a strong binding between the
   "creator" and the "product". 
   The code designer can use this fact to cluster the strongly related 
   objects together [using (Factory) Methods in the creator object] and
   decouple the client application from the strong cluster.

   Then the client code can only hold a reference to a generic
   creator object (say the root object/interface of the creators'
   class hierarchy). The actual creator can be loaded at runtime
   and get referenced by the generic-creator-reference present in the
client.

2. I have a question here, can you give me a scenerio where a "product"
   of the Factory Method pattern should be used as a creator in turn 
   (thus forming a chain which can extend), rather than having more than
   one (factory) methods in the primary creator itself ?

   I mean should we ever need n-level deep factory method structure 
   rather than one-leve deep - as discussed in GOF?
   If yes when, and if not why not ?


Regards,
Prabodh

<<attachment: winmail.dat>>