一、创建型模式：工厂方法模式（Factory Method）

请MM去麦当劳吃汉堡，不同的MM有不同的口味，要每个都记住是一件烦人的事情，我一般采用Factory Method模式，带着MM到服务员那儿，说“要一个汉堡”，具体要什么样的汉堡呢，让MM直接跟服务员说就行了。

定义  

        核心工厂类不再负责所有产品的创建，而是将具体创建的工作交给子类去做，成为一个抽象工厂角色，仅负责给出具体工厂类必须实现的接口，而不接触哪一个产品类应当被实例化这种细节。

使用场景

        不管是简单工厂模式，工厂方法模式还是抽象工厂模式，他们具有类似的特性，所以他们的适用场景也是类似的。

        首先，作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过new就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。

       其次，工厂模式是一种典型的解耦模式，迪米特法则在工厂模式中表现的尤为明显。假如调用者自己组装产品需要增加依赖关系时，可以考虑使用工厂模式。将会大大降低对象之间的耦合度。

       再次，由于工厂模式是依靠抽象架构的，它把实例化产品的任务交由实现类完成，扩展性比较好。也就是说，当需要系统有比较好的扩展性时，可以考虑工厂模式，不同的产品用不同的实现工厂来组装。

优缺点分析

优点：

1、多态性：客户代码可以做到与特定应用无关，适用于任何实体类。

2、子类提供挂钩。基类为工厂方法提供缺省实现，子类可以重写新的实现，也可以继承父类的实现。— 加一层间接性，增加了灵活性

3、连接并行的类层次结构。

4、良好的封装性，代码结构清晰。

5、扩展性好，在增加产品类的情况下，只需要适当修改具体的工厂类或扩展一个工厂类，就可“拥抱变化”。

6、屏蔽产品类。产品类的实现如何变化，调用者都不需要关心，只需关心产品的接口，只要接口保持不变，系统中的上层模块就不会发生变化。

7、典型的解耦框架。高层模块只需要知道产品的抽象类，其他的实现类都不需要关心，符合迪米特法则，符合依赖倒置原则，符合里氏替换原则。

缺点：

需要Creator和相应的子类作为factory method的载体，如果应用模型确实需要creator和子类存在，则很好；否则的话，需要增加一个类层次。

角色及其职责

抽象工厂(Creator)角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。

具体工厂(Concrete Creator)角色：这是实现抽象工厂接口的具体工厂类，包含与应用程序密切相关的逻辑，并且受到应用程序调用以创建产品对象。

抽象产品(Product)角色：工厂方法模式所创建的对象的超类型，也就是产品对象的共同父类或共同拥有的接口。

具体产品(Concrete Product)角色：这个角色实现了抽象产品角色所定义的接口。某具体产品有专门的具体工厂创建，它们之间往往一一对应。

工厂方法模式UML图

  

应用场景及代码分析

       程序员小明开面包店有一段时间了，一直使用简单工厂模式实现面包店的代码，今天他学习到了一种新的面包制作方法，于是要在店里添加这种新的面包，于是他着手修改自己的面包店代码，他发现需要添加一个新的面包类，同时也要修改简单工厂类，增加Case分支，很明显对扩展开放的同时，也对修改开放了，这可不符合“开放-封闭原则”，那怎么修改现在的代码呢，经过一番学习以后，他发现了工厂方法模式。

       首先将我们的面包师和面包写出来：

//面包师，作为父类public class BreadMaker {//生产面包public  void getBread(){//等待孩子们生产出来}}//奶油面包public class ButterBread extends BreadMaker{// 覆盖父类方法@Overridepublic void getBread() {// TODO Auto-generated method stubsuper.getBread();System.out.println("烤出了奶油面包");}}//巧克力面包public class ChocolateBread extends BreadMaker{// 覆盖父类方法@Overridepublic void getBread() {// TODO Auto-generated method stubsuper.getBread();System.out.println("烤出了巧克力面包");}}//香蕉面包public class BananaBread extends BreadMaker{// 覆盖父类方法@Overridepublic void getBread() {// TODO Auto-generated method stubsuper.getBread();System.out.println("烤出了香蕉面包");}}

根据定义，我们需要一个用于创建对象的接口

//工厂接口public interface IFactory {BreadMaker CreateBread();}

不同的面包建立一个具体工厂方法来实现这个接口

//奶油面包的工厂方法实现public class ButterBreadFactory implements IFactory{@Overridepublic BreadMaker CreateBread() {//返回奶油面包实例return new ButterBread();}}//巧克力面包的工厂方法实现public class ChocolateBreadFactory implements IFactory{@Overridepublic BreadMaker CreateBread() {//返回巧克力面包实例return new ButterBread();}}//香蕉面包的工厂方法实现public class BananaBreadFactory implements IFactory{@Overridepublic BreadMaker CreateBread() {//返回香蕉面包实例return new ButterBread();}}

现在小明又开始重新开张了：

//工厂方法模式测试public class FactoryMethodTest {public static void main(String[] args){System.out.println("小明面包店开始营业！");BreadMaker breadMaker = null;IFactory breadFactory = null;System.out.println("顾客要一个奶油面包");//根据需要实例化接口breadFactory = new ButterBreadFactory();breadMaker =breadFactory.CreateBread();breadMaker.getBread();System.out.println("顾客要一个巧克力面包");breadFactory = new ChocolateBreadFactory();breadMaker =breadFactory.CreateBread();breadMaker.getBread();System.out.println("顾客要一个香蕉面包");breadFactory = new BananaBreadFactory();breadMaker =breadFactory.CreateBread();breadMaker.getBread();}}

输出结果：

小明面包店开始营业！

顾客要一个奶油面包

烤出了奶油面包

顾客要一个巧克力面包

烤出了奶油面包

顾客要一个香蕉面包

烤出了奶油面包

简单工厂模式PK工厂方法模式

       简单工厂模式虽然并不在GOF的23中设计模式中，却被广泛地应用。简单工厂最大的优点是去除了客户端与具体产品的依赖，因为工厂类包含了需要的逻辑判断。虽然简单工厂违背了“开放-封闭原则”，但保持了封装对象创建过程的优点。

       可以说工厂方法模式是简单工厂模式的进一步使用，也可以说简单工厂模式是工厂方法模式的简化。对于多态性的进一步使用，工厂方法模式在保留简单工厂模式优点的同时，也克服了它的缺点。

       工厂方法模式也有其缺点，每增加一个产品，就要相应的添加一个产品的工厂类，增加了额外的开发量。

       

简单工厂模式与工厂方法模式的选择

       选择简单工厂模式和工厂方法模式，要取决于具体的应用，对于比较简单的应用，“产品”比较少时，使用简单工厂模式就可以满足要求。对于产品比较丰富的应用，过多的判断分支不利于程序的维护，这时应该选择工厂方法模式来降低程序的维护量。