工厂方法模式

也可以参考这一篇，总结很到位：https://blog.csdn.net/jerry11112/article/details/80618420

之前提到了简单工厂模式，里面用条件判断形势来生产不同类别的产品，但是存在一个问题，就是增添新品种的产品时，要修改工厂里的判断分支语句，添加上新品的if判断语句（或者修改代码，增添case分支语句来满足新品种），这就破坏了开放-关闭原则，要对增加开放，对代码修改关闭。

ConcreteProduct具体产品是ConcreteCreator具体工厂方法FactoryMethod里面的一个局部变量，关系比较弱，所以是依赖关系（如果产品是工厂的成员变量，那就是关联关系，比较强，用实线了）

为了解决这个问题，就将工厂类变成抽象的或者接口，每个产品都对应一个实现了工厂接口的工厂类，这样再有添加新品种产品需求的时候，就直接在代码里面添加新产品的类（实现产品接口），同时再添加对应的工厂实现类，这样就不需要那个简单工厂里面的判断分支，自然也就不需要在有新产品需求的时候修改里面简单工厂类里面的代码了，相当于把判断分支改成了用新建具体的类的形式实现，添加新品种就添加新的产品和工厂类，主程序中直接new新的工厂类就行，删减产品，就直接把具体产品的实现类和工厂实现类删除就行（或者不删，留着不用就行），满足了开放封闭原则。

依赖关系在uml图中使用虚线箭头的形式，大的范围指向小的范围，例如工厂指向产品。模板见下图，动物和水以来关系，动物的方法：新陈代谢中有水和氧气，动物使用到了氧气和水，工厂生产过程中用到了产品对象，所以他俩是依赖关系。

 

简单工厂模式的好处在于，我们把条件判断的过程从主程序中封装提取了出来，这样就可以在不同的地方复用这个工厂

 

 

但是其实在需求改动的时候还要改动代码，这样不太好，最好能将要变动的地方用字符串当做变量，这个变量从配置文件中读取键值来得到，例如大话设计模式里面之前的都要new 对应的数据库工厂在代码里，还是会出现当数据库更改的时候，要在客户端里面修改工厂的名字的情况，已然修改了代码，所以利用反射就更好了，反射生产对象所需的参数可以从配置文件里面读取出来。这样就解决了耦合的问题。