抽象工厂模式是工厂模式的升级。相对而言，抽象工厂模式并不像工厂模式那么好理解，看了不少网上博客的描述，感觉都说说的云里雾里，个人觉得还是把抽象问题具体化更好。推崇《大话设计模式》中的讲解模式。本文讲以更通俗的语言，结合《大话设计模式》中使用的实例，把抽象工厂模式理清楚。
1. 对工厂模式的回顾
先总结下个人对工厂模式的理解：
工厂模式中的类主要分两大类群，一是产品类群，而是工厂类群。
工厂类群这边，把生成产品的步骤，提取出来并做了抽象，即：工厂基类中抽象出的createOperation()方法，具体的建造过程是在具体产品对应的工厂类中实现的。
产品类群这边，将所有产品所共有的一些行为抽象了出来，比如上图中的operation()方法，某个具体产品是怎样进行operation()的需要各个具体产品类自己去定义和实现。
总的来说，工厂模式是一个具体的工厂类对于一个具体产品类。当一个工厂需要生产多个产品时，是不是就傻眼了？这时候就需要“抽象工厂模式”闪亮登场了。
2. 《大话设计模式》中抽象工厂模式的具体案例：
实际项目工作中经常会涉及数据库的读写，这必然要从多个主流的数据库产品中选择一个，在自己的项目中使用。
一个项目做好后，如果换个用户，必然要对原项目进行修改，如果新用户提出换一种数据库，问题出来了：在项目的功能需求一致的情况下，数据库中所要创建和使用的table的结构肯定是一样的，数据处理逻辑也一样，但是，不同类型的数据库，比如Oracle和Access，具体的建表语句和访问语句是不一样的；如果，不提前抽象出建表逻辑、和数据处理逻辑，那在更换数据库过程中，必然带来庞大而混乱的工作量。
此时，我们就可以把一种数据库（database）当做一种工厂（product creator），每个数据库都对应有几个相同的表要生成，所以，可以把待建的某个table当做成一个product。
接着进行抽象操作：
产品端：每种产品都是一种Table，对应同一个表结构，每一种Table又有多种不同Database的实现形式
工厂端：每种工厂都是一种Database，对应可以生成相同外观的表，每一种Database又可以生成多种Table
3. 引出“抽象工厂模式”
以上是Database-Table的示例结构图，将Table转化成Product，Database转化中Creator之后边可得到抽象工厂模式的结构图：
从项目中使用一个新的数据库（工厂）的角度，只需要新增一个Creator_3类，同时新增Product_A_C3和Product_B_C3；此时客户端的调用中，只需要修改Creator creator = new Creator_3()，其他位置的调用无须修改，满足“修改封闭-扩展开放”原则。
如果是项目中新增一个Product，则会麻烦一些，此时Product端要新增对于多个Creator的产品类；同时，Creator端要对Creator的结构进行调整，主要是新增CreatPC()接口函数，各个Creator实现类也要对应新增。客户端的代码里也需要根据实际需要做修改。