https://www.jianshu.com/p/38bd26a1f7ef

工厂模式的实现方式和原理都不难理解和掌握。但是，在学习完之后，发现网上给的例子，根本体现不了工厂模式的作用。先不说存在有的例子本身就是错误的，主要是例子中的代码太简单，可以说没必要用工厂模式，只不过是为了说明实现方式和原理。所以，会产生一种错觉：还不如直接new 一个对象来的方便，有效。

的确，设计模式本身就有其适用的场景，并不是滥用的，否则还不如不用。

首先， 工厂模式是为了解耦：把对象的创建和使用的过程分开。就是Class A 想调用 Class B ，那么A只是调用B的方法，而至于B的实例化，就交给工厂类。

其次， 工厂模式可以降低代码重复。如果创建对象B的过程都很复杂，需要一定的代码量，而且很多地方都要用到，那么就会有很多的重复代码。我们可以这些创建对象B的代码放到工厂里统一管理。既减少了重复代码，也方便以后对B的创建过程的修改维护。（当然，我个人觉得也可以把这些创建过程的代码放到类的构造函数里，同样可以降低重复率，而且构造函数本身的作用也是初始化对象。不过，这样也会导致构造函数过于复杂，做的事太多，不符合java 的设计原则。）

由于创建过程都由工厂统一管理，所以发生业务逻辑变化，不需要找到所有需要创建B的地方去逐个修正，只需要在工厂里修改即可，降低维护成本。同理，想把所有调用B的地方改成B的子类B1，只需要在对应生产B的工厂中或者工厂的方法中修改其生产的对象为B1即可，而不需要找到所有的new B（）改为new B1()。

另外， 因为工厂管理了对象的创建逻辑，使用者并不需要知道具体的创建过程，只管使用即可，减少了使用者因为创建逻辑导致的错误。

举个例子：

一个数据库工厂：可以返回一个数据库实例，可以是mysql，oracle等。

这个工厂就可以把数据库连接需要的用户名，地址，密码等封装好，直接返回对应的数据库对象就好。不需要调用者自己初始化，减少了写错密码等等这些错误。调用者只负责使用，不需要管怎么去创建、初始化对象。

还有，如果一个类有多个构造方法（构造的重写），我们也可以将它抽出来，放到工厂中，一个构造方法对应一个工厂方法并命名一个友好的名字，这样我们就不再只是根据参数的不同来判断，而是可以根据工厂的方法名来直观判断将要创建的对象的特点。这对于使用者来说，体验比较好。

工厂模式适用的一些场景（不仅限于以下场景）：

1. 对象的创建过程/实例化准备工作很复杂，需要初始化很多参数、查询数据库等。

2.类本身有好多子类，这些类的创建过程在业务中容易发生改变，或者对类的调用容易发生改变。