Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

difference between factory pattern , abstract factory pattern and command pattern

 
anagha patankar
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 105
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 762
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 71
Java Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.



Cheers
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic