设计模式—工厂模式与抽象工厂模式

工厂模式与抽象工厂模式都属于创建型模式
两者一般会在书籍里面分开来讲，但是我觉得两者其实在本质上没有什么大的区别，反而有一种互通的地方，因此我们会把它们放在一起。
老样子，我们来看他们的定义与UML图。

看出来有什么相似的地方了么？
其实两个模式都是一样的，只是抽象工厂模式将抽象更进了一步，什么都用抽象，在具体的客户端调用的时候也用抽象来调用。而工厂模式就是有什么用什么，不来虚的。
继续提示：我们应当以接口编程而不是具体实例（反复提示加深影响，因为这个概念在看图的时候十分有用）

我们来秀代码（抽象工厂模式）：
工厂的抽象类（依赖倒转原则）：

abstract class Factory{
       getProduct(){}
}

产品抽象类：

interface Product{
}


abstract  ProductA implements Product {
}
abstract  ProductB  implements Product {
}

产品具体实例：

class ConreteProductA extend ProductA{
}
class ConreteProductB extend ProductB{
}

工厂具体实例：

class ConreteFactoryA extend Factory{
      getProduct(){
              return new ConreteProductA ();
      }
}
class ConreteFactoryB extend Factory{
    getProduct(){
              return new ConreteProductB  ();
      }
}

创造者类（通过它来调用具体工厂类，为什么要加上它，而不是在使用者里面直接这样写？因为少些代码啊！！！）：

class Creator{
      Product  getInstance(Factory factory){
           return Factory.getProduct();
      }
}

使用者：

Creator creator = new Creator ()
creator.getInstance(new ConreteFactoryA ());//这里就是所说的具体实例在使用的时候确定
creator.getInstance(new ConreteFactoryB ());

以上就是抽象工厂模式，其实也可以说是工厂模式。
工厂模式、抽象工厂模式的通俗化解释其实都一样：就是通过一个工厂类的方法获得实例，而不是自己new出来。

至于为什么要不断抽象？
因为这样在通用类编程的时候，比如Creator类中，你就可以通过接口来调用，而不需要通过具体类了（通过具体类，你则需要写两个getInstance，因为两个Factory不一样），至于在具体环境里面你想需要什么工厂，则在使用者里面具体调用。
有人会问了，这样的话使用者不是违反了最少指导原则么，每次业务变了都要修改它啊！
当然要修改了，使用者就是业务逻辑，业务变了逻辑当然会变了！！！
我们学习设计模式，不是为了业务变了什么都不用改，这个肯定无法实现，而是为了改的少！在这里里面当业务变了，但是工厂没变得时候，你只需要改使用者就行了，其他的你一个都不需要改，这样已经很省事了！