Factory Method

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Reverted edits by Ebybymic (Talk); changed back to last version by Benjamin Gibson)
 
(9 intermediate revisions by 7 users not shown)
Line 17: Line 17:
 
* A class wants its subclasses to specify the objects it creates.
 
* A class wants its subclasses to specify the objects it creates.
 
* Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.
 
* Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.
 
  
 
== How it works (Structure) ==
 
== How it works (Structure) ==
  
Let a subclasses of the creator create an instance of a specific product. Creator class uses whatever the Product in the same way.
+
The Factory Method lets a subclass of the Creator class create an instance of a specific product. Users of the factory method can then use the product without knowing specifically what type of product it is.
  
[[Image:Factory Method.jpg]]
+
[[Image:FactoryMethod.png|500px]]
  
In the above diagram the anOperation() method has some code like:
+
Typical creation of a product might be as follows:
  
  product = FactoryMethod();
+
  Creator c;
 
+
Product p;
and the concrete implementation of the factoryMethod() in the ConcreteCreator class would have some code like:
+
 
+
someMethod()
  return new ConcreteProduct;
+
{
 +
    c = new ConcreteCreator();
 +
    p = c.factoryMethod();
 +
    p.doStuff();
 +
  }
  
 
==== Participants ====
 
==== Participants ====
Line 42: Line 45:
 
== Consequences ==
 
== Consequences ==
  
Factory methods eliminate the need to tie application-specific classes into your code. Your code will only have to deal with the Product interface, so this means it can work with any concrete subclass of Product. For example:
+
* Factory methods eliminate the need to tie application-specific classes into your code. Your code will only have to deal with the Product interface, so this means it can work with any concrete subclass of Product.<br>The code above, for example, is good because we don't care which subclass of Product p was actually instantiated with. We just call the method doStuff() which is defined in the abstract Product class and the subclass of Product that p was instantiated with just performs its concrete implementation of the doStuff() method.
  
Creator c;
+
* Clients might have to subclass the Creator class if they want to create a ConcreteProduct. This means that clients must now deal with any changes in the Creator class and overall need more knowledge of that part of the system.
Product p;
+
+
someMethod()
+
{
+
    c = new ConcreteCreator();
+
    p = c.factoryMethod();
+
    p.doStuff();
+
}
+
  
This code is good because we don't care which subclass of Product p was actually instantiated with. We just call the method doStuff() which is defined in the abstract Product class and the subclass of Product that p was instantiated with just performs its concrete implementation of the doStuff() method.
+
* Factory methods provide hooks for subclasses who want to provide an extended version of an object, making extension easy. It makes your code more flexible than if you just create the object directly.
 +
 
 +
*Factory methods can be used to connect parallel class hierarchies.
 +
 
 +
*Violates the [[Dependency inversion principle]]
 +
 
 +
== Example ==
 +
 
 +
You can find [http://java.dzone.com/articles/design-patterns-factory here] a nicely explained java code example of the Factory Method Pattern usage in the real world.
  
 
== Recognising the pattern ==
 
== Recognising the pattern ==
Line 63: Line 66:
 
* abstract Creator class.
 
* abstract Creator class.
 
* Product interface/abstract class.
 
* Product interface/abstract class.
 +
 +
==Related Patterns==
 +
* [[Abstract Factory]]: A Factory Method pattern is often used to implement part of an [[Abstract Factory]].
 +
* [[Template Method]]: Factory Methods are often called as part of a [[Template Method]].
 +
* [[Prototype]]: [[Prototype]] is a similar pattern but doesn't require subclassing the Creator. On the other hand, it needs an initialize operation on the Product class which is not required by Factory Method.
 +
* [[Dependency injection]]
  
 
==See also==
 
==See also==
 
*[[Abstract Factory]]
 
*[[Abstract Factory]]
 +
 +
{{design patterns}}

Latest revision as of 03:23, 25 November 2010

(This is summarised from GoF design patterns book)

Contents

Intent

The factory method is useful when you wish to define an interface for creating an object, but you want to let subclasses decide which class to create. Factory Method lets an abstract/normal class defer instantiation of an object of a different class to subclasses of the abstract/normal class.

It allows all fields of a particular type to be of an abstract type so that the class is more general. the factory can then be chosen to provide the concrete type that are desired for the fields.

This pattern is sometimes also called Virtual Constructor.

When to use it (Applicability)

Useful when:

  • A class cannot anticipate the class of an object it must create.
  • A class wants its subclasses to specify the objects it creates.
  • Classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

How it works (Structure)

The Factory Method lets a subclass of the Creator class create an instance of a specific product. Users of the factory method can then use the product without knowing specifically what type of product it is.

FactoryMethod.png

Typical creation of a product might be as follows:

Creator c;
Product p;

someMethod()
{
    c = new ConcreteCreator();
    p = c.factoryMethod();
    p.doStuff();
}

Participants

  • Product: this defines the interface of objects the factory method creates.
  • ConcreteProduct: this implements the Product interface.
  • Creator: this class declares the factory method, which will return an object of type Product. Creator may also define a default implementation of the factory method that returns a default ConcreteProduct object but this really depends on what behaviour the developer requires. Creator, although abstract may have a method like the anOperation() method mentioned above, that simply calls the factoryMethod() to create a Product object.
  • ConcreteCreator: this class overrides the factoryMethod() to return an instance of ConcreteProduct.

Consequences

  • Factory methods eliminate the need to tie application-specific classes into your code. Your code will only have to deal with the Product interface, so this means it can work with any concrete subclass of Product.
    The code above, for example, is good because we don't care which subclass of Product p was actually instantiated with. We just call the method doStuff() which is defined in the abstract Product class and the subclass of Product that p was instantiated with just performs its concrete implementation of the doStuff() method.
  • Clients might have to subclass the Creator class if they want to create a ConcreteProduct. This means that clients must now deal with any changes in the Creator class and overall need more knowledge of that part of the system.
  • Factory methods provide hooks for subclasses who want to provide an extended version of an object, making extension easy. It makes your code more flexible than if you just create the object directly.
  • Factory methods can be used to connect parallel class hierarchies.

Example

You can find here a nicely explained java code example of the Factory Method Pattern usage in the real world.

Recognising the pattern

Classes: Creator, ConcreateCreator, Product, ConcreteProduct

  • abstract protected createProduct() in Creator that returns a Product.
  • concrete override of createProduct() in ConcreteCreator.
  • abstract Creator class.
  • Product interface/abstract class.

Related Patterns

See also


Personal tools