同为创造型设计模式的简单工厂模式可以理解为对new关键字的代替。
本着重复三次即重构的原则，如果一个对象在不同的地方被new了两次以上，那就可以考虑使用它。那我们为什么要用简单工厂模式代替new呢？就像我们使用Getter Setter代替直接读写字段一样，说白了就是加上一个间接层，以缓冲处理流程的变化(比如获取字段的时候，为其加上100再返回，写在Getter里就不需要散弹式修改)。
相比起来工厂方法模式无疑复杂了很多。引用一句维基百科上对其用途的解释:
Deal with the problem of creating objects without having to specify the exact class of the object that will be created
也就是说用在不想直接引用精确类型来创建对象的时候。等等，不引用精确类型那不就是多态吗，那我们直接用
AInterface a;
//TODO: 对a依赖注入
a.work();
AInterface b;
//TODO: 对b进行不同精确类型的依赖注入
b.work();这样的形式不就行了吗？
如果这样就能解决问题，当然可以这样用，毕竟重构只在必要的时候去做。但是对a进行依赖注入的工作肯定不会自动完成，为了解决这个问题出现了一大批依赖注入框架。如果你不想用笨重的框架，那你就得自己去创建a的实例，然后理所当然的你就必须知道a的精确类型，毕竟你不能直接new一个接口，至少在java里是这样。所以你有了这样的代码：
AInterface a;
a = new AInterfaceImpl();
a.work();
AInterface b;
b = new BInterfaceImpl();
b.work();事实上，恶心的工作不会消失不见，顶多可以把恶心的工作延迟完成，不然我们的程序不可能跑得动。在上面的需求里，你不能永远忽视a的精确类型，就算用依赖注入框架也是一样的，在程序的某个地方，你必须给它一个明确的类型。但是，程序员的美德是，复杂的工作，永远要推迟到后面去实现，至少在上面的代码里，我想要隐藏精确类型，比如像这样：
Factory factory;
//TODO: 对factory依赖注入
//看，用起来很简单对吧
AInterface a;
a = factory.getIt();
a.work();
//TODO: 对factory进行不同的依赖注入
//用多态的特性做不同的工作
AInterface b;
b = factory.getIt();
b.work();好吧，我们解决了一个问题，然后引入了另一个问题。现在我们必须关心Factory的精确类型了。我们不停地把垃圾扔给别人，以保持自己的干净。
对于不停传递垃圾这种行为我已经累了，不想写了，但是工厂方法模式当然还没有结束，有空再写吧