looking closely at the abstract factory & factory method patterns I'm sort of wondering whats the difference between them is.
As, I could easily change the factory method pattern to be the abstract factory pattern by implementing a new factory (deriving from the 'Creator' interface) and implementing a new object hierarchy (deriving from the interface returned from the factory) ?? Note that changing from factory method to abstract factory would not change any existing implementation.
Finally, the factory method pattern defines an interface for creating an object but lets the subclass decide which class to create -- this is also what the abstract factory pattern does.
Its debatable. I can argue that EJBHome is an example of Abstract Factory. The client composes the home interface and calls a create method to get the component interface. Because composition is used, one can say it is an Abstract Factory. The home interface is the abstract factory and the EJB container creates the implementation. The component interface is the abstract product and the implementation is again created by the container. The client composes the abstract factory (home interface) and calls a create method on the abstract factory to create the product. Because composition is used, this is a case of an abstract factory that happens to have only 1 product in its family (the EJBObject implementation)
Joined: May 01, 2006
So, this can be interprated as abstract factory pattern is also factory pattern but factroy pattern is not nessarily abstract factory one.
Originally posted by Santiago Urrizola: .. abstract factory creates a family of related objects ...
Correct. Also keep in mind that the factory method is a building block in the Abstract Factory Pattern. Furthermore Factory Method sometimes refers to a looser concept than initially defined in GOF. You see an example of this in Fowler's "Replace Constructor with Factory Method". Notice that the factory method does not "defer instantiation to subclasses", nor is there any sign of an interface method that must be implemented, nor could it be because here the factory method is a (static) class method.
Originally posted by John Waugh: EJBHome is an example of Factory Pattern.
It would be more accurate to state that the EJB create method is an example of the Factory Method Pattern. However GOF purist could nitpick and say that is not a Factory Method because the create method isn't part of the EJBHome interface - it only exists due to conventions set up by the EJB specification. So really, the EJB create method isn't a Factory Method in the strict GOF sense. However the intent of the EJB create method is consistent with Fowler's usage of the term Factory Method.
Originally posted by B Sathish: Because composition is used, one can say it (EJBHome) is an Abstract Factory.
Actually the fact that the returned object is a composite has not bearing in the Abstract Factory pattern. Ultimately EJBHome is about the creation of a representation of a single type of object � the bean that it serves. The finder methods simply return collections of the same representation and in my book that does not constitute "creating families of related or dependent objects". The remaining methods are helper methods that have nothing to do with creation (we are talking about creational patterns here). So I would not cite EJBHome as an example of an Abstract Factory.
A better candidate for an Abstract Factory is the JDBC driver interface as described by the specification. The driver most definitely creates "families of related or dependent objects". However most people never notice because they actually implement against a particular vendor implementation using a vendor dialect of SQL. However it is possible to only use the functions as specified by the specification to achieve "plug-ability" of various drivers implementing the same level of the specification. Of course you would need another Abstract Factory to provide you with the vendor-dependent SQL renditions (and dependent objects) for that to work. [ May 06, 2006: Message edited by: Peer Reynders ]
thanks for the great clarification (and the time you might have spent on it!). Great!
Originally posted by Peer Reynders: Factory Method sometimes refers to a looser concept than initially defined in GOF. You see an example of this in Fowler's "Replace Constructor with Factory Method". Notice that [there] the factory method does not "defer instantiation to subclasses", nor is there any sign of an interface method that must be implemented, nor could it be because here the factory method is a (static) class method.
This differenc might be the reason for getting this question again and again.
First, as a Java developer, I thought of static factory methods only and did not understand the world anymore when reading "the" changed definition like "defer instantiation to subclasses".
The static method understanding is the more intuitive one, is not wrong but not the official whole, so everybody should define which strategy of this pattern he is talking about.
It is sad that the authors of "defer instantiation to subclasses" did not mention the strategy of a static method too.
Can some one please clarify this notion of saying FactoryMethod --> Inheritence, AbstractFactory --> Composition. I read this in a lot of books/articles infact HeadFirst suggests this in one of its Bean Interviews...
I was trying to digest this for long now but could really get to it. I can understand FactoryMethod --> Inheritence but how about AbstractFactory --> Composition.
Hi, i post an image that helps me a lot to undertand the diference betwen this two patterns.
My notes to undertand when i was study for the first part(perhaps not the best): Method Factory: only one create method, and create only object of one family Abstract Factory: * creational methods, each of one create object of an especific family. So an ejbhome contains * create method, that is the form that i undertand wy the ejbobjetc is an AbstractFactory.
Joined: Aug 19, 2005
Originally posted by Rajesh Velicheti: Can some one please clarify this notion of saying FactoryMethod --> Inheritence, AbstractFactory --> Composition.
Head First sticks to the GoF-purist notion of a Factory Method. So the "inheritance part" is based on the idea that each class that implements the Factory Method separately and that each may return a distinct subclass (of the base class/interface identified by the Factory Method's return type) from their concrete method. However with Fowler's Factory Method the "inheritance part" is simply based on the fact that the concrete method will return an unknown subclass(/implementing class) from the inheritance hierarchy(/all the classes implementing the interface) of the class(/interface) specified as the factory method's return type.
Now the Abstract Factory -> "composition part" is a popular notion but ultimately misleading . If a class has a Factory Method that returns an object that is a composition (whole-part) but there is no other factory method on that class that may return some other part ("part" rather then the "whole") then you are not dealing with an Abstract Factory � you are still only dealing with a Factory Method. The Abstract Factory's primary concern is the "creation" of different object instances belonging to different classes (belonging to different inheritance hierarchies) of a family of classes that may be created and returned separately. Composition is usually a secondary effect because these parts usually fit together in some way � but that�s not a necessary condition for the Abstract Factory. Furthermore the Factory has to be abstract, i.e. the concrete factory actually has to implement an interface (or extend an abstract class) that specifies the "contract" of the Abstract Factory. So really it should be Abstract Factory -> "instances from a family of classes/interfaces".
Originally posted by Santiago Urrizola: So an ejbhome contains * create method, that is the form that i undertand wy the ejbobjetc is an AbstractFactory.
What are the classes in the family of classes of which the EJBHome creates instances? The creational methods are not part of the EJBHome interface; they are part of the bean's home interface! The create method(s) on the home interface only return objects of one polymorphic type - the component interface (collections of instances from classes implementing the component interface returned by the finder methods don't count as a family of classes).
The create method(s) of the bean's home interface are the Factory Methods. There are no Factory Methods on the EJBHome interface.
The home interface create methods return instances implementing the component interface (and collections thereof), not "objects from a family of classes". Therefore the bean's home interface doesn't qualify as an Abstract Factory.
Furthermore neither EJBObject nor a bean's component interface contain any creational methods.