一、工厂方法
工厂方法模式他提供了一个抽象类（接口），子类实现该接口的某个方法，来创建自己的工厂，因此是子类来决定要“创建哪个工厂”。
二、抽象工厂
抽象工厂提供一个接口，通过实现该接口，创建一系列产品家族，每个工厂负责创建指定的产品（这更像是单一单一职责原则）。
三、两种方法的异同
工厂方法和抽象工厂的异同，如果从方法层面看这两种模式，会感觉这两种方法实现的效果十分的类似，不是吗？再客户端方法中，调用了这两者的方法，实现了动态性，区别在于。抽象方法在调用阶段还没有确定获取的是哪一个“实体”，必须根据传入参数来判断，而抽象工厂在实例化工厂的时候已经指定了。因此工厂方法更加适用于一对多，而抽象工厂适用于多对一（如果一对一就完全没必要了，直接实现就行了）。
四、思考与分析
依赖倒置的思路：改变我们原有的从顶端开始思考问题的思路，而是根据最后我们到底要得到什么来思考问题，因为有时候像树那样的一级一级的去思考问题，你会发现代码的复杂度会指数倍爆炸，这里可以拿工厂模式来举例子，假如A工厂生产B造机床，B机床又可以看出一种工厂（负责生产C榨汁机器），C榨汁机又可以做多种饮料D。这里如果从A开始，把所有的实现放在A实现类中，那么情况会是o(n^3)，，这显然不是我们需要的），那么，我们可以进行解耦，拿B来说，A和C不需要直接关联，只有通过B才需要负责C的职责（A说：C不在我的负责之内，我只管给你什么参数，你会返回我什么），显然这又满足了迪米特原则。好吧，回到原来的问题，A生产B，那么我们对B进行了抽象，A中只需要存在一个B的抽象，再通过抽象工厂方法创建出B的实例。到了这里A的工作就完成了，不需要去关心C的创建，一个模块任务完成。那么C创的创建就交给B了，也是同理。可以发现通过上面这种方式，将A的o（n^3）感觉业务逻辑变的平行了（实际没有改变最后饮料的创建数量）。这就是设计模式的神奇之处。
