difference between factory pattern , abstract factory pattern and command pattern

[anagha patankar]

Hello ,
Read the sun website regrading these patterns and I am confused .
I dont seem to be seeing any difference between these patterns .

Am I missing something ? To my novice mind all seem to be similar / same

Regards ,
-anagha

[Naveen K Garg]

Hi Anagha,

Please see if this helps:

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

This means that an abstract Creator class defines an abstract create method (or provides a default create method) which returns an abstract Product. A ConcreteCreator class implements the abstract create method to return a ConcreteProduct. This enables the Creator to defer Product creation to a subclass. Factory Method is often used in the Abstract Factory pattern to implement the create methods

Pros.
� shields clients from concrete classes
� if a framework uses the Factory Method pattern, it enables third-party developers to plug-in new Products
� the Creator create method can be coded to return a default Product

Cons.
� coding a new Product means writing two classes � one for the concrete Product and one for the concrete Creator
� static � inheritance based

Abstract Factory:

Provide an interface for creating families of related or dependent objects without specifying their concrete classes

This means that a �family� of abstract create methods (each of which returns a different AbstractProduct) are grouped in an AbstractFactory interface.
ConcreteFactory implementations implement the abstract create methods to
produce ConcreteProducts.

Pros.
� shields clients from concrete classes
� easy to switch product family at runtime � just change concrete factory
� �keep it in the family� � enforces product family grouping

Cons.
� adding a new product means changing factory interface + all concrete factories

Command:

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

The purpose of the Command pattern is to decouple an event generator (the Invoker) from the event handler (the Receiver). A ConcreteCommand class (sub-classed from Command) defines an execute () method which calls the appropriate method on the Receiver (the action method). The client is responsible for associating the Receiver with the Command and then the Command with an Invoker.

Pros.
� decouples Invoker from Receiver � makes Receiver more re-usable as it
doesn�t manage the relationship with the Invoker
� Command encapsulate a request � requests can be stored so they can be
undone, processed at a later time, etc.
� extensible � easy to add new Commands
� macros � commands can be grouped into macros so that multiple commands can
be run at once
� dynamic � e.g. different Commands, multiple Invokers, decide at runtime, etc.

Cons.
� can�t centralise related action methods in one Command class - only one method is used (execute ())

For more details regarding above patterns please refer Design Patterns - Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (also known as the Gang of Four, or GoF)

Regards
Naveen Garg

[Peer Reynders]

With regard to the creational patterns see also the following topics:
Builder Pattern Question
abstract and abstract factory
Abstract Factory vs Factory pattern

[Stan James]

I'm bothered by GoF's definitions more and more over time. Both Factory Method and Abtract Factory have the following:

* An abstract class with a creation method
* Concrete creator classes that create things
* An abstract thing that gets created
* Concrete things that get created

Factory Method has one creation method, possibly among other methods. Abstract Factory has creation methods for a family of things and no other methods (in the example diagram).

The implementations are much more alike than they are different. Add a second creation method for a related thing to a Factory Method and you have an Abstract Factory. The diagrams in the book look nothing alike, but they could if you wanted them to.

[Ilja Preuss]

Originally posted by Stan James:
The implementations are much more alike than they are different.

I always understood it the way that the deciding difference between Factory Method and Abstract Factory is the same as between Template Method and Strategy: the former is class based, the latter object based.

With other words, a Factory Method uses inheritance - the base class declares the abstract creation method and uses it internally, subclasses provide the definition for the creation method.

An Abstract Factory is used by composition - the base class often is a purely abstract class (or interface), and instances of conrete implementations are passed to its clients, which aren't related to the factories by inheritance.

Does that make sense?

[Stan James]

Yes, good. You've mentioned that distinction before but I hadn't fully let it sink in. I was just thinking about Abstract Method diagrams showing no client. The class with the factory method can be its own client, typical of Template.

I hadn't thought of Abstract Factory necessarily as a strategy. It works very nicely that way, though there may be other ways to look at it.

For both the question of how the cliente gets to a particular concrete creator is left open. For Abstract Factory you mentioned "concrete implementations are passed to its clients", I guess as dependency injection because that fits your composition suggestion.

We had one consultant who wanted a FactoryFactory all the time. Seems like that might never end.

[Jigar Naik]

Factory Method has one creation method, possibly among other methods. Abstract Factory has creation methods for a family of things and no other methods (in the example diagram).

The implementations are much more alike than they are different. Add a second creation method for a related thing to a Factory Method and you have an Abstract Factory. The diagrams in the book look nothing alike, but they could if you wanted them to.

Can i say AbstractFactory returns Factory ?
Can i say AbstractFactory returns Factory and from that Factory we get the instance of concrete product ?
Can i say Factory is subset of AbstractFactory ?

[sourabh girdhar]

Can i say AbstractFactory returns Factory and from that Factory we get the instance of concrete product ?

I think this is the best logical derivation. In simple terms even I would say "Abstarct factory is another layer of abstraction over factory". "It gives you Factory to create Objects".

The best example I can find out is the JAXP factories. We get the factory from factory builder and then Documents from the factory.

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder db = dbf.newDocumentBuilder(); 
Document doc = db.parse(new File(filename));

Cheers