简单工厂模式

简单工厂模式的作用在于解决开发过程中模块与模块之间的耦合性， 使得各个模块之间的功能划分更加清晰，对于设计模式的理解需要结合具体的应用场景才能深入理解，本文将通过一个具体的业务场景来说明简单工厂设计模式的优点以及什么场景下适合用简单工厂模式。
某天你所在的软件公司突然接到一个开发的任务，要帮助某个销售汽车的4s店做一个网站，作为项目组长的你把这个任务分配给了程序猿小A,小B和小C, 其中小A主要负责关于各类汽车信息的开发，小B要负责将各类汽车的配件参数取出传给前端进行展示，小C主要负责将各类汽车的价格提供给前端进行展示。接到上述任务后，三只后端的程序猿经过一番彼此沟通，拿到的各自任务模型图如下：

上面的图的意思是，A程序员定义了两种汽车的类，并把两类汽车的配置信息和价格设定为类对象属性，B程序员和C程序员由于需要使用A程序员汽车类的一些信息，于是就在各自的类中根据输入信息的不同，创建不同的汽车类对象，并其将对应类型汽车的信息返回。上面这种逻辑看上去没什么毛病， 但是从下面的角度思考一下，还是有一些问题的。

这种设计实际上是耦合性太强，代码不利于扩展。想想这么一个场景，如果程序中又增加了一个奥迪的车型，A程序员这时候会定义一个奥迪车的类，B和C程序员此时还需要去更改自己类中的代码，如果还有其它的程序员或者的类需要用到了汽车类，则都需要去更改自己的代码，这显然是一种不合理的设计模式。

对于上述的设计怎么优化呢？我们可以看出B和C关心的只是自己拿到的对象，对于函数中的if判断语句是迫于输入的信息不确定才写的，而且任何与汽车类相关的类都需要重写一遍这些判断的冗余代码，很简单的一种思想就是我们将创建汽车对象的过程抽离出来，放在一个单独的类中，这样其它类在使用汽车类时就不必自己单独进行汽车对象的创建，只需要去调用特定的类中调取特定的方法，就可以拿到自己需要的对象，这样既降低了程序的耦合性，增加了模块的单一职责性和可扩展性，又降低了代码的冗余度，避免了侵入式的开发。(已经完成的代码尽量不再修改)

talk is cheap, i will show my model.

更改后的代码实现如下图所示：

通过上面的修改，无论以后增加多少种汽车，只需要A在 carFactory里修改一遍代码，其它的类无需修改自己类中的代码，就可以拿到增加的汽车的信息，这种设计方式叫做简单工厂模式。

说了这么多，总结一下应用简单工厂模式的场景，如果用户需要应用某一种功能的几个类的实例，而这种功能的类以后还有可能会扩展增加，我们通常 会用一个工厂类，将用户需要的实例在工厂中创建之后并返回，工厂类中会完成一些常见的判断操作，从而适配不同的用户类所需要的对象。