前言
在设计模式有三个模式是与工厂模式相关的，分别是：简单工厂模式、工厂方法模式以及抽象工厂模式。在前面的文章中已经谈到前面两种，这里就对抽象工厂模式介绍一下。抽象工厂模式就是提供一个创建一系列相关或者相互依赖的接口（也就是抽象类），而无需指定具体的类。简单来说，就是当我们需要创建一个具体的对象的时候，我们不必指定该具体的对象，只需要使用它的上层接口直接调用就行。好像还是很抽象哦，好吧，为了更清晰领悟这个设计模式，我们还是通过一个案例来说明
某公司开发了一个a软件，数据库使用的是sqlserver。后由于客户要求需要使用oracle数据库，原来的数据要迁移到oracle中，在迁移的过程中遇到很多问题，比如语法错误，关键字滥用，函数不支持等问题。请设计一组程序，实现数据的无缝迁移。
通过使用我们的工厂方法模式，我们已经较好的解决了用户使用不同数据库的问题，现在我们已经获得了要创建的数据库对象，那么接下来我们就需要向数据库中添加数据了，假设都需要添加部门信息，有的用户需要使用oracle，有的用户需要使用sqlserver。考虑抽象工厂模式的代码结构：
在修改代码结构之前，为了更好的对比，来看一下我们现在的代码结构：
原始代码v1.0：
根据抽象工厂模式结构图以及需求，修改代码如下：
1) 增加一个创建部门的抽象工厂，这里使用接口
2) 分别创建基于oracle以及基于sqlserver的部门实现类（已经在上面的代码中实现）
3) 创建一个数据库工具类，根据条件创建需要的对象
修改的代码v1.1
这里通过dbaccess类直接替代了原来的ifactory、oraclefactory、sqlserverfactory三个类，这里实际上是简单工厂的实现方法，把判断逻辑转移到dbaccess中，客户端不需要做任何修改，要更换数据库只需要在dbaccess中把dbtype的值修改就ok。在这点上，好像简单工厂占优势，但是不尽然，如果要在程序中添加对mysql数据库的支持，如果使用原来抽象工厂模式。只需要添加一个mysqlfactory类就行，现在就需要在dbaccess类中修改逻辑判断了（在这一点违背了封闭开放原则）。那么有没有一种方法，不要增加对switch的判断就可以根据dbtype的值创建相应的对象呢？也就是说，在程序运行期间，根据类的字符串表示创建类的实例。答案是肯定的，在java中我们可以利用反射技术做到这一点，所以我们对v1.1版的代码进行进一步的修改：
v1.2
现在，如果需要增加对mysql的支持只需要修改oracle为mysql就行，不过还是得创建mysqlobject类以及mysqldepartment类，但是与上面简单工厂模式的修改不同，这里只是在原来代码的基础增加，是扩展而不是修改。所以没有违背开放-封闭原则，现在这版的代码比之前好多了，但是dbtype的值仍然不可避免要进行修改，事实上还有一种通过配置文件的方式可以保存原来的代码不变而实现这个功能，下面对代码进行第三次修改：
首先创建db.properties配置文件
v1.3版代码
客户端代码保持不变，实际测试成功。
从v1.0到v1.3我们对工厂模式做一个简单的小结：
所有使用简单工厂的都可以考虑使用反射技术加以优化
抽象工厂的最大好处是便于交换产品系列，要创建不同的产品，我们可以使用不同的工厂创建。所以当我们需要不同产品线的产品的时候只需要换一个工厂就可以轻松实现
抽象工厂模式与工厂方法模式把创建实例的过程与客户端分离，用户操作的只是抽象接口，而具体的创建过程则封装到了具体的工厂去实现。很好的体现了开放-封闭的原则
抽象工厂模式与抽象工厂模式都存在一个缺点，就是需要增加新功能的时候，要创建的类很多。
简单工厂模式可以通过反射技术克服上诉缺点，但使用反射会降低程序的性能，所以虽然使用反避免了创建多个类的麻烦，却也同时降低了程序的性能，所谓有得必有失。在实际的开发中还是需要仔细衡量的。