【设计模式】——工厂三姐妹

    

      对于工厂三姐妹，她们之间是各有各的优点，各有各的用途，但都是属于创建型模式。通过看《大话设计模式》和百度搜索，对其有了些基本的了解，就来分别介绍三姐妹的详细情况：

    一、简单工厂模式

      她是三姐妹中最简单实用的一种模式，但她并不属于23种GOF设计模式之一。

      我们拿具体的例子来说吧，每个公司都需要有管理采购的部门，我们就以采购为例。采购的简单工厂模式结构图如下：

      实质：

        采购部门根据采购工厂传入的采购清单参数来动态的决定由哪位采购员去采购；

      优点：

        工厂类包含了必要的逻辑判断，可以根据客户端的选择条件动态实例化相关的类，对于客户端来说，去除了与具体产品的依赖。

      缺点：

        违背了开放—封闭原则，由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中；它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。适用于工厂类负责创建对象比较少的情况。

    二、工厂方法模式

      她克服了简单工厂的缺点，是对简单工厂的优化。

      定义：

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

      还是以上的采购模式来画出工厂方法模式的结构图：

      采购即为所创建的对象接口，在此实例中，由采购单来决定需要哪一个采购员类去采购物品，将实例化延迟到了采购的子类采购单中。一个具体采购单对应一个具体的采购员。

          适用情况:

            第一种情况是对于某个产品，调用者清楚地知道应该使用哪个具体工厂服务，实例化该具体工厂，生产出具体的产品来。

                   第二种情况，只是需要一种产品，而不想知道也不需要知道究竟是哪个工厂为生产的，即最终选用哪个具体工厂的决定权在生产者一方，它们根据当前系统的情况来实例化一个具体的工厂返回给使用者，而这个决策过程这对于使用者来说是透明的。

      三、抽象工厂模式

        定义：

               提供一个创建一系列相关或相互以来对象的接口，而无需指定它们具体的类。
抽象工厂模式是对开放—封闭原则和依赖倒转原则的良好运用，还是以采购为例，我们来看一下抽象工厂的结构图与其它两姐妹的差别：

                  这个模式是指有多个抽象角色，大白菜和胡萝卜是两个分别抽象出来的对象，它们又分别对应着多个子类，采购员A和采购员B分别采购两种蔬菜并送到不同的部门，每种蔬菜只分别负责自己的子类。

        优点：

          易于交换产品系列，在抽象工厂模式中工厂类更为具体，所以改变一个应用的具体工厂非常容易，比如部门A可以改成部门C，只需要将原来的‘采购 factory=new 部门A()’改为‘采购 factory=new 部门C()’，只需要改变具体工厂就可以使用不同的配置；

          具体的创建实例过程与客户端分离，就像在采购例子中，使用者只知道有‘大白菜’和‘胡萝卜’，至于这两种蔬菜分别是谁买的，使用者就不知道这些了。

        缺点：

          如果我们需要在采购中增加内容，就不是那么简单了，如果我们想添加一种蔬菜：小油菜，那就需要我们添加小油菜的工厂类、采购员和采购部门，改动很多，极其的不方便。

        适用情况：

       1.系统不依赖于产品类实例如何被创建、组合和表达的细节；
       2.系统的产品有多于一个的产品类，而系统只消费其中某一类的产品；
       3.同属于同一个产品类是在一起使用的，这一约束必须在系统的设计中体现出来；
       4.系统提供一个产品类的库，所有产品以同样的接口出现，从而使客户端不依赖于实现。

      四、总结

          总的来说，工厂三姐妹都是对程序设计优化的模式，各有各的特征与优点，又分别适用于不同的情况。不同情况下选用不同的模式，在之后的不断实践中加强应用掌握。

          这只是我对三姐妹的浅薄理解，有错误之处，还望各位大神斧正！