What is the difference between factory method and abstract factory design patterns?

What is the difference between factory method and abstract factory design patterns ?I am confused about both . Does abstract factory use factory method to implement itself?

Please开发者_Python百科 give some tangible examples .

Factory Pattern in general comes from the thought that Object instantiation is an important thing and it should not be scattered accross code but should be done from a Centralised Location to have more control; it is neater as well.

Factory Method is just serving the above Purpose

     ControlFactory
 {
  public Button GetButton(){return new Button();}
  public Label GetLabel(){return new Label();}
  public TextBox GetTextBox(){return new TextBox();}
 }

Then for instantiating these controls you will be writng below code

ControlFactory cf=new ControlFactory();

Button b=cf.GetButton();b.Text="Click Me";
Label l=cf.GetLabel();

Abstract Factory on the other hand is helpful to deal with object families. Eg: If you plan different versions of your software for free and paid users you may choose to use ordinary controls for Free version and some aesthetically better controls for the paid version. This can be handled elegantly with Abstract Factory Pattern.

 abstract class ControlsFactory
 {
    public abstract Button GetButton();
    public abstract Label GetLabel();
 }

---now FreeControlFactory and ExoticControlFactory inherits from above class

 class FreeControlsFactory:ControlsFactory
 {


  public override Button GetButton()
  {
      return new FreeButton();//Assume that **FreeControl** and **ExoticControl** are Inherited From **Control** 
  }

  public override Label GetLabel()
  {
      return new FreeLabel();
  }

 }

...

 class ExoticControlsFactory : ControlsFactory
 {


  public override Button GetButton()
  {
   return new ExoticButton();
  }

  public override Label GetLabel()
  {
   return new ExoticLabel();
  }

 }

Assume that FreeControl and ExoticControl are Inherited From Control (I am not writing the code here)

Now you will be writing below code to switch all the controls to another version

if (VersionKey=="FreeVersion")
    {ControlFactory cf= new FreeControlFactory();}
ese if (VersionKey=="PaidVersion")
    {cf=new ExoticControlFactory();}

based on above selection all the places Controls will be switched

Button b1=cf.GetButton();//b1 will be based on which family cf is containing
Button b2=cf.GetButton();
Button b3=cf.GetButton();
Label l1= cf.GetLabel();
Label l2= cf.GetLabel();

It is the polymorphic behaviour that helps here , ie cf can contain either freefactory or exoticfacctory. and that decides which controls are created.

Use the Factory pattern to directly create subclasses, for example

class CatFactory
{
    ICat Create(string name);
}

CatFactory = new CatFactory();
ICat myCat = myCatFactory.Create("Lion")

An Abstract Factory takes it further by defining an interfaces that the factories must implement, for example ICatFactory, which decouples you from using an particular factory class.

interface ICatFactory
{
    ICat Create(string name);
}

How do you create instances of the abstract factory? A factory factory is probably the simplest way to understand conceptually, but in practice the easiest (depending on the scale of your application) might be to use a Dependency Injection framework, which provide a lot of helper functionality for decoupling classes.

ICatFactory = DependencyInjector.Get<ICatFactory>();
ICat myCat = myCatFactory.Create("Lion")

or depending on the framework just

ICat myCat = DependencyInjector.Get<ICat>("Lion")

A factory method hides the construction of a single object; it can be used to implement virtual constructors. Another special case of a factory method is the "clone" method used in the prototype pattern. Factory methods are simply functions returning new objects.

An abstract factory hides the construction of a family of related objects. Abstract factories are usually implemented using (a set of) factory methods. For instance, imagine you want to make your GUI implementation independant of any particular toolkit. You might decide to have abstract classes for different controls, as well as an abstract factory to create controls:

class Button { };
class Label { };
class CheckBox { };

class Toolkit {
public:
    virtual ~Toolkit() {}
    virtual Button *createButton() = 0;
    virtual CheckBox *createCheckBox() = 0;
    virtual Label *createLabel() = 0;
};

You could then implement the abstract toolkit class as well as the abstract control classes for each toolkit, e.g.:

class QtButton : public Button { };
class QtLabel : public Button { };
class QtCheckBox : public Button { };

class QtToolkit {
public:
    virtual ~Toolkit() {}
    virtual Button *createButton() { return new QtButton; }
    virtual CheckBox *createCheckBox() { return new QtCheckBox; }
    virtual Label *createLabel() { return new QtLabel; }
};

The code which actually constructs the GUI only needs an Toolkit*, so there is very low coupling:

void constructGUI( Toolkit *tk )
{
   Button *okButton = tk->createButton();
   okButton->setText( "OK" );

   // ...
}

This decouples a client using a set of related objects (in this case: GUI controls) from the implementaiton of the controls.