设计模式_2_简单工厂、工厂方法、抽象工厂比较

    这三个模式主要的应用场景是：当创建单个（简单工厂、工厂方法）或多个（抽象工厂）系列对象，客户程序为了生成某个具体对象判断复杂，可能多处使用，并且在添加新的实现或新的系列时，需要过多改动已有的客户代码，为了解决这些问题，出现了这三种套路。（篇幅有限就不贴代码了）

    首先，简单工厂：

    在简单工厂中（应对于生成单系列的对象），客户程序仅依赖于Factory和Product类，而不依赖于具体的实现类，CreateProduct方法用于根据传入的参数，生成不同的对象，实际上就是将客户程序中对生成不同实现对象的重构，将创建对象的方法，封装到一个方法中，在这里我们封装成一个工厂类，将生成不同对象的判断逻辑放到一个单独的类中。

    然后，是工厂方法，在简单工厂中，如果需要添加新的一种实现，那就要改过工厂类的方法，这样工厂类就违背了对修改关闭、对扩展开放的原则。在某些情况下，我们的框架无法修改具体创建的工厂类。例如，ADO.NET数据访问程序，sql server组件方式的实现与my sql组件的实现，当my sql实现时，不可能要求MS为它加一个判断分支吧（当然这种情况是不存在的了），我们这里先将这个应用场景看成是单系列，那我们现有的解决方案是简单工厂，而简单工厂缺点是把生成对象判断的逻辑放在了组件中。当我们开的组件要求可以让第三方实现新的实现时，显然这种方式是不可取的。而工厂方法可以解决这一问题 。

    工厂方法（Factory Method），定义一个用于创建对象的接口，让子类决定实例化哪一个类，工厂方法使一个类的实例化延迟到其子类。

    最后，抽象工厂，还是上面ADO.NET数据访问组件的实现例子，在实现各种访问组件时，不可能只有一个类吧，最少也要大于20个类吧，对于这种多系列对象创建工作工厂方法显然不然正常的工作（如果每一个系列有20个类，那么就会有20个抽象类，N*20实现类，并且当一个系列中实现类有关系时）。

    抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。即当遇到需要创建多个系列，并且每一个系列中的类相互依赖时，可以考虑用抽象工厂。