静态工厂、工厂方法、抽象工厂
1.简单工厂模式（静态工厂）
参与者：
·抽象产品角色（AbstractProduct）
所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。
·具体产品角色（ConcreteProduct）
继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的 应该是该角色的某一具体产品
·工厂角色（Creator）
简单工厂模式的核心，负责实现所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。
工厂类实现：
public class Factory
{
public ICoat CreateCoat(string styleName)
{
switch (styleName.Trim().ToLower())
{
case "business":
return new BusinessCoat();
case "fashion":
return new FashionCoat();
default :
throw new Exception("还没有你要的那种衣服");
}
}
}
优点：
·简单工厂模式能够根据外界给定的信息，决定究竟应该创建那个具体类的对象。
·外界与具体类分开，耦合性低。
·明确区分了各自的职责和权力，有利于整个软件体系结构的优化。
缺点：
·简单工厂模式所能解决的问题时有限的，他所能创建的类对象只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类。
应用场景：
·工厂类负责创建的类比较少
·客户只知道传入了工厂类的参数，对于如何创建对象不关心
2.工厂方法模式（工厂模式）
在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化哪一个类。
在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不接触哪一个产品类被实例化这种细节。这使得工厂模式可以允许系统在不修改工厂角色的情况下引进新产品。
参与者：
·抽象产品角色：定义产品的接口
·具体产品角色：事先接口Product的具体产品类
·抽象工厂角色：声明工厂方法，返回一个产品
·真实的工厂：事先抽象工厂的方法，由客户调用，返回一个产品的实例
UML图示
优点：
·基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象。而且如何创建一个具体产品的细节完全封装在具体工厂内部，符合高内聚，低耦合。
·在系统中添加新产品时，无需修改抽象工厂和抽象产品提供的接口，无需修改客户端，也无需修改其他的具体工厂和具体产品，很好的利用了封装和委托。
缺点：
·在添加新产品时，需要编写新的具体产品类，要增加与之对应的具体共产类。
应用场景：
·类不知道自己要创建哪一个对象
·类用它的子类来制定创建哪个对象
·当类将创建对象的职责委托给多个帮助类中的某一个，并且希望你将哪一个帮助子类是代理者这一信息局部化的时候。
3.抽象工厂
在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作，同时由于需求的变化，往往存在着更多系列对象的创建工作。
抽象工厂设计意图：“提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。”
这个模式之所以称之为AbstractFactory，是因为它要创建的东西本身是由抽象定义的，工厂各种变化的实现如何选择，模式并没有具体规定。而并不是因为工厂是用每种情况有一个派生类的抽象类实现的。
UML图：
参与者：
·抽象产品角色（AbstractProduct）
所有具体产品角色的父类，它负责描述所有实例所共有的公共接口。
·具体产品角色（ConcreteProduct）
继承自抽象产品角色，一般为多个，是简单工厂模式的创建目标。工厂类返回的 应该是该角色的某一具体产品
·工厂角色（Creator）
简单工厂模式的核心，负责实现所有具体产品类的实例。工厂类可以被外界直接调用，创建所需的产品对象。
工厂类实现：
public class Factory
{
public ICoat CreateCoat(string styleName)
{
switch (styleName.Trim().ToLower())
{
case "business":
return new BusinessCoat();
case "fashion":
return new FashionCoat();
default :
throw new Exception("还没有你要的那种衣服");
}
}
}
优点：
·简单工厂模式能够根据外界给定的信息，决定究竟应该创建那个具体类的对象。
·外界与具体类分开，耦合性低。
·明确区分了各自的职责和权力，有利于整个软件体系结构的优化。
缺点：
·简单工厂模式所能解决的问题时有限的，他所能创建的类对象只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类。
应用场景：
·工厂类负责创建的类比较少
·客户只知道传入了工厂类的参数，对于如何创建对象不关心
2.工厂方法模式（工厂模式）
在工厂方法模式中，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象，这样做的目的是将类的实例化操作延迟到子类中完成，即由子类来决定究竟应该实例化哪一个类。
在工厂方法模式中，核心的工厂类不再负责所有产品的创建，而是将具体创建工作交给子类去做。这个核心类仅仅负责给出具体工厂必须实现的接口，而不接触哪一个产品类被实例化这种细节。这使得工厂模式可以允许系统在不修改工厂角色的情况下引进新产品。
参与者：
·抽象产品角色：定义产品的接口
·具体产品角色：事先接口Product的具体产品类
·抽象工厂角色：声明工厂方法，返回一个产品
·真实的工厂：事先抽象工厂的方法，由客户调用，返回一个产品的实例
UML图示
优点：
·基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够使工厂可以自主确定创建何种产品对象。而且如何创建一个具体产品的细节完全封装在具体工厂内部，符合高内聚，低耦合。
·在系统中添加新产品时，无需修改抽象工厂和抽象产品提供的接口，无需修改客户端，也无需修改其他的具体工厂和具体产品，很好的利用了封装和委托。
缺点：
·在添加新产品时，需要编写新的具体产品类，要增加与之对应的具体共产类。
应用场景：
·类不知道自己要创建哪一个对象
·类用它的子类来制定创建哪个对象
·当类将创建对象的职责委托给多个帮助类中的某一个，并且希望你将哪一个帮助子类是代理者这一信息局部化的时候。
3.抽象工厂
在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作，同时由于需求的变化，往往存在着更多系列对象的创建工作。
抽象工厂设计意图：“提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。”
这个模式之所以称之为AbstractFactory，是因为它要创建的东西本身是由抽象定义的，工厂各种变化的实现如何选择，模式并没有具体规定。而并不是因为工厂是用每种情况有一个派生类的抽象类实现的。
UML图：
