views:

103

answers:

3

My understanding of Factory Method Pattern is (Correct me if i am wrong)

Factory Method Pattern

"Factory Method allow the client to delegates the product creation (Instance Creation) to the subclass".

There are two situation in which we can go for creating Factory Method pattern.

(i) When the client is restricted to the product (Instance) creation.

(ii) There are multiple products available.But a decision to be made which product instance need to be returned.

If you want to create Abstract Method pattern

  • You need to have abstract product
  • Concrete Product
  • Factory Method to return the appropriate product.

Example :

public enum ORMChoice
{
  L2SQL,
  EFM,
  LS,
  Sonic
}
//Abstract Product
public interface IProduct
{
   void ProductTaken();
}
//Concrete Product
public class LinqtoSql : IProduct
{
  public void ProductTaken()
  {
    Console.WriteLine("OR Mapping Taken:LinqtoSql");
  }
 }
//concrete product
 public class Subsonic : IProduct
 {
    public void ProductTaken()
    {
       Console.WriteLine("OR Mapping Taken:Subsonic");
    }
 }
//concrete product
 public class EntityFramework : IProduct
 {
    public void ProductTaken()
    {
       Console.WriteLine("OR Mapping Taken:EntityFramework");
    }
  }
//concrete product
 public class LightSpeed : IProduct
 {
   public void ProductTaken()
   {
     Console.WriteLine("OR Mapping Taken :LightSpeed");
    }
  }

 public class Creator
 {
    //Factory Method 
    public IProduct ReturnORTool(ORMChoice choice)
    {
      switch (choice)
      {
        case ORMChoice.EFM:return new EntityFramework();
        break;
        case ORMChoice.L2SQL:return new LinqtoSql();
        break;
        case ORMChoice.LS:return new LightSpeed();
        break;
        case ORMChoice.Sonic:return new Subsonic();
        break;
        default: return null;
      }
  }

 }

**Client**

Button_Click()
{
 Creator c = new Creator();
 IProduct p = c.ReturnORTool(ORMChoice.L2SQL);
 p.ProductTaken();

}

Is my understanding of Factory Method is correct?

A: 

What you have there is actually more of an Abstract Factory Pattern, only that you factory (Creator) is not abstract. The factor method pattern is specifically useful for subclassing:

class A {
public:
    A() : m_Member( GetMember() ) 
    {
    }
protected:
    virtual ISomeInterface * GetMember() { // default impl here }
private:
    ISomeInterface * m_Member;
}

Now subclasses of A can override GetMember to make the superclass use a specific implementation of ISomeInterface.

Space_C0wb0y
hahaha, this really made me laugh when you were correcting me about this **not** being a *Factory Pattern*!! I'm in no way arguing with you but just read that out loud. With a slight change of words: "What you have is an *Abstract Factory Pattern* only that your factory is not abstract". Wouldn't an *Abstract Factory Pattern* without the abstract part be a *Factory Pattern*? ;-) (Complete tongue-in-cheek here - I'm not familiar with the difference between the two.)
Jaxidian
I get how that sounds funny. However, I choose the wording because the abstract factory pattern has two degrees of freedom: the factory, and the products. The case where there is only ever one factory (and hence no need for it being absract) happens very often, at least in my experience, and can be considered a special case. Also, the GOF-book lists the pattern as abstract factory pattern, and using the correct names is important.
Space_C0wb0y
So it does! In fact, the first thing inside the book, on the front cover, is a blurb about Abstract Factory. I now remember when I first read that I thought, "That sounds like a standard Factory pattern." I did that with quite a few of their patterns. However, I do wanna chomp a bit here about your "correct names" comment - there are SOO many names for the same thing that are all considered "correct". Just because the GOF calls it something, even though that's kinda **the book** for patterns, doesn't mean it's the only correct one. It is, after all, pretty dated...
Jaxidian
A: 

Yes, that appears to be a correct way to implement this, although pretty simplistic. In reality, you may want to account for the passing-in of various parameters that may not always be consistent across all types. Dictionaries/Lists/Hashtables/etc. are useful for this, as is serialized items and/or XML and other dynamicish things.

Jaxidian
-1 because, as I pointed out in my answer, this not a factory method, so this is not a correct way to implement this.
Space_C0wb0y
+1  A: 

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

more details and example there: http://www.dofactory.com/Patterns/PatternFactory.aspx

Amr ElGarhy