请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{
// 覆盖父类方法
@Override
public void getBread() {
// TODO Auto-generated method stub
super.getBread();
System.out.println("烤出了奶油面包");
}
}
//巧克力面包
public class ChocolateBread extends BreadMaker{
// 覆盖父类方法
@Override
public void getBread() {
// TODO Auto-generated method stub
super.getBread();
System.out.println("烤出了巧克力面包");
}
}
//香蕉面包
public class BananaBread extends BreadMaker{
// 覆盖父类方法
@Override
public void getBread() {
// TODO Auto-generated method stub
super.getBread();
System.out.println("烤出了香蕉面包");
}
}
根据定义，我们需要一个用于创建对象的接口
//工厂接口
public interface IFactory {
BreadMaker CreateBread();
}
不同的面包建立一个具体工厂方法来实现这个接口
//奶油面包的工厂方法实现
public class ButterBreadFactory implements IFactory{
@Override
public BreadMaker CreateBread() {
//返回奶油面包实例
return new ButterBread();
}
}
//巧克力面包的工厂方法实现
public class ChocolateBreadFactory implements IFactory{
@Override
public BreadMaker CreateBread() {
//返回巧克力面包实例
return new ButterBread();
}
}
//香蕉面包的工厂方法实现
public class BananaBreadFactory implements IFactory{
@Override
public 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中设计模式中，却被广泛地应用。简单工厂最大的优点是去除了客户端与具体产品的依赖，因为工厂类包含了需要的逻辑判断。虽然简单工厂违背了“开放-封闭原则”，但保持了封装对象创建过程的优点。
可以说工厂方法模式是简单工厂模式的进一步使用，也可以说简单工厂模式是工厂方法模式的简化。对于多态性的进一步使用，工厂方法模式在保留简单工厂模式优点的同时，也克服了它的缺点。
工厂方法模式也有其缺点，每增加一个产品，就要相应的添加一个产品的工厂类，增加了额外的开发量。
简单工厂模式与工厂方法模式的选择
选择简单工厂模式和工厂方法模式，要取决于具体的应用，对于比较简单的应用，“产品”比较少时，使用简单工厂模式就可以满足要求。对于产品比较丰富的应用，过多的判断分支不利于程序的维护，这时应该选择工厂方法模式来降低程序的维护量。