简单工厂、工厂方法和抽象工厂

学前理解：
1.概念理解：面向接口编程的示意图

2.相関概念
1.产品：类
2.抽象产品：抽象类、接口
3.产品簇：多个有内在联系，或者是有逻辑关系的产品。比如三秦套餐中，凉皮+冰峰+肉夹馍
4.产品等级：

简单工厂：

这种设计相当脆弱！为什么呢？因为，只要作者修改了具体产品的类名，那么，客户端代码也要随之一起改变，这样，服务器端代码和客户端代码就是耦合的。我们希望的效果是：无论服务器端代码如何修改，那么客户端代码都应该不知道，不用修改客户端代码！

针对于上述问题，服务器端代码一旦修改，客户端代码也要跟着修改！
修改代码如下，使用简单工程设计模式！

任何下层给上层暴露出的方法都可以称作接口。客户端只按接口编程。隔离变化。
简单工厂：
优点：
1.把具体产品的类型，从客户端代码，解耦出来。
2.服务器端，如果修改了具体产品的类名，客户端也不知道。
这便符合了面向接口编程的思想。
缺点：
1.客户端不得不死记硬背数字与具体产品的映射关系，比如1对应汉堡包，2对应米线。
2.如果具体产品特别多，则简单工厂，就会变得十分臃肿。比如有100个产品，则需要在简单工厂的switch中写100个case.
3.最重要的是，客户端需要扩展产品，是必要的修改简单工厂的代码，这违反了开闭原则。
简单工厂 的UML类图

工厂方法
针对于简单工厂的问题，修改代码如下，使用工厂方法设计模式。

工厂方法：
优点：
1.仍然具有简单工厂的优点，服务器端修改了具体产品的类名以后，客户端不知道啊！
2.当客户端需要扩展一个新产品时，不需要修改作者原来的代码，只是扩展一个新的工厂而已！
杠点：
1.我们已经知道，简单工厂也好，工厂方法也好，都有一个优点，就是服务器端的具体产品类名变化了以后，客户端不知道！但是，反观我们现在的代码，客户端依然依赖于具体的工厂的类名呀！此时，如果服务器端修改了具体工厂的类名，那么客户端也要随之一起修改！感觉折腾了一圈，又回到了原点！
解释：
工厂的名字，是视为接口的。作者有责任，有义务，保证工厂的名字是稳定的。也就是说，虽然客户依赖于工厂的具体类名，可是在IT业内，所有的工厂的名字都是趋向于稳定（并不是100%不会变）。至少工厂类的名字，要比具体产品类的名字更加稳定！
杠点：
2.既然产品是我们自己客户端扩展出来的，那么为什么不自己直接实例化呢？毕竟这个扩展出来的LP这个产品，我们自己就是作者。
设计代码如下：


解释：
因为，作者在开发功能时，不仅仅只会开发一些抽象产品、具体产品、对应的工厂，还会配套的搭配一些提前做好的框架。（例如：框架为提高其扩展性，形参为工厂，而你没有做工厂，那么就不能使用框架。）
杠点：
3.现在制作出LpFactory,是为了把LpFactory传入给Bussiness.taste方法，所以，必须定义这个LpFactory工厂。那为什么不从一开始就让Bussiness.taste方法就直接接收Food参数呢？而不是现在的工厂。
例如：


解释：
又回到了起点。一个是这是同一个对象，另外，如果产品名称改变，那么不好维护。
工厂方法模式的UML类图

缺点：
如果有多个产品等级，那么工厂类的数量，就会产生爆炸式增长。

抽象工厂
针对工厂方法的问题，当有多个产品等级时，（食物、饮料、甜品…），工厂类就会很多！！
修改代码如下，将代码修改为抽象工厂设计模式。
原代码：




将代码修改为抽象工厂设计模式：





抽象工厂的UML类图

优点：
1.仍然有简单工厂和工厂方法（扩展性好）的优点。

2.更重要的是，抽象工厂把工厂类的数量减少了。无论有多少个产品等级，工厂就一套。
杠点：
1.为什么三秦工厂中，就必须是米线搭配冰峰呢？为什么就不能是米线搭配可乐？
解释：在抽象工厂中，可以生产多个产品，这多个产品之间，必须有内在联系。同一个工厂中的产品都属于同一个产品簇。不能把不同产品簇中的产品混合到一个抽象工厂的实现类中。
缺点：
1.当产品等级发生变化时，（增加产品等级、删除产品等级），都要引起所有以前工厂代码的修改。这就违反了开闭原则。注意：增加产品簇时，不会修改。

结论：
当产品等级比较固定时，可以考虑抽象工厂，如果产品等级经常变化，不建议使用抽象工厂。

不同场景下：
如果产品等级只有1个，那么工厂方法反而比抽象工厂更好。
作者保证产品不扩充，使用简单工厂。
如果产品等级很多，用抽象工厂。
如果产品等级经常变化，不用抽象工厂。（Spring 动态工厂加反射可以解决。）