简单工厂模式,工厂方法模式,抽象工厂模式,spring的狂想

      菜鸟D在项目中遇见一个比较纠结的高耦合，所以就想办法来解耦。情况是这样的：系统通过用户选择treeview控件的节点判断调用不同的处理，这些处理中某些东西又是类似的。同事的建议是采用简单工厂，耦合就耦合吧，反正treeview节点基本是不会变化的。（能偷懒就偷懒吧）

      菜鸟D有些偏执，想找些方法来解耦。于是就学习了这个几种方法，虽然不一定用的上，多学一点总是好的。

      首先说简单工厂，例子是一个已经二到死的计算器。

      简单工厂由三种角色组成：工厂类角色（creator），抽象产品类角色（product,图中为Iproduct接口），具体产品类角色（concreteproduct,图中为Product_A…）。

    代码如下：

public class Calculate
    {
        public double DValue1 { get; set; }
        public double DValue2 { get; set; }

        public virtual double GetResult()
        {
            return 0;
        }
    }

    public class Add : Calculate
    {
        public override double GetResult()
        {
            return DValue1 + DValue2;
        }
    }

    public class Sub : Calculate
    {
        public override double GetResult()
        {
            return DValue1 - DValue2;
        }
    }

    public class Mul : Calculate
    {
        public override double GetResult()
        {
            return DValue1 * DValue2;
        }
    }

    public class Div : Calculate
    {
        public override double GetResult()
        {
            if (DValue2.Equals(0))
            {
                if (DValue1.Equals(0))
                {
                    return 1;
                }
                return 0;
            }
            return DValue1 / DValue2;
        }
    }

            #region 客户端
            Console.WriteLine("请输入第一个数");
            string v1 = Console.ReadLine();
            Console.WriteLine("请输入运算符");
            string oper = Console.ReadLine();
            Console.WriteLine("请输入第二个数");
            string v2 = Console.ReadLine();
            Calculate c = GetCalculateByOper(oper);
            c.DValue1 = Convert.ToDouble(v1);
            c.DValue2 = Convert.ToDouble(v2);
            Console.WriteLine("结果：" + c.GetResult()); 
            #endregion

        #region 工厂方法
        private static Calculate GetCalculateByOper(string oper)
        {
            Calculate c = new Calculate();
            switch (oper)
            {
                case "+": c = new Add();
                    break;
                case "-": c = new Sub();
                    break;
                case "*": c = new Mul();
                    break;
                case "/": c = new Div();
                    break;
            }
            return c;
        } 
        #endregion    

      在这个例子中没有使用抽象类，接口，而是用了虚方法（纯粹是不想在接口里定义属性，自己喜欢用什么就用什么，毕竟这不是简单工厂的核心）。简单工厂的核心是充当工厂类角色的工厂方法（起码在此例中是这样），逻辑判断中使具体产品类和工厂直接耦合了（好像类图的关系已经决定了这种耦合，但是将具体产品和客户端解耦）。如果要添加一个开方运算，首先添加开方的运算类，然后打开工厂方法进行修改。（呵呵，违反了开闭原则）

     接下来再说一下工厂方法模式，类图如下：

      先分析一下类图，工厂模式有了四个角色：工厂接口，工厂实现，产品接口，产品实现（其实说角色不贴切，还不如说是种类）。工厂实现和产品实现有了依赖关系，通过调用工厂实现来获取产品实现。也就是一种产品实现对应一种工厂实现。

     还是那个二的要死的计算器的例子，代码如下：

    public interface IFactory
    {
        ICalculatable GetCalculatable();
    }

    public interface ICalculatable
    {
        double GetReslut(double d1, double d2);
    }

    public class Add : ICalculatable
    {
        public double GetReslut(double d1, double d2)
        {
            return d1 + d2;
        }
    }

    public class AddFactory : IFactory
    {
        public ICalculatable GetCalculatable()
        {
            return new Add();
        }
    }

    public class Sub : ICalculatable
    {
        public double GetReslut(double d1, double d2)
        {
            return d1 - d2;
        }
    }

    public class SubFactory : IFactory
    {
        public ICalculatable GetCalculatable()
        {
            return new Sub();
        }
    }

    public class Mul : ICalculatable
    {
        public double GetReslut(double d1, double d2)
        {
            return d1 * d2;
        }
    }

    public class MulFactory : IFactory
    {
        public ICalculatable GetCalculatable()
        {
            return new Mul();
        }
    }

    public class Div : ICalculatable
    {
        public double GetReslut(double d1, double d2)
        {
            if (d2.Equals(0))
            {
                if (d1.Equals(0))
                {
                    return 1;
                }
                return 0;
            }
            return d1 / d2;
        }
    }

    public class DivFactory : IFactory
    {
        public ICalculatable GetCalculatable()
        {
            return new Div();
        }
    }

#region 逻辑判断
    public class Factory
    {
        public static IFactory GetCalculatableByOper(string oper)
        {
            IFactory factory = null;
            switch (oper)
            {
                case "+": factory = new AddFactory();
                    break;
                case "-": factory = new SubFactory();
                    break;
                case "*": factory = new MulFactory();
                    break;
                case "/": factory = new DivFactory();
                    break;
            }
            return factory == null ? null : factory;
        }
    } 
#endregion

            #region 客户端
            Console.WriteLine("请输入第一个数");
            string v1 = Console.ReadLine();
            Console.WriteLine("请输入运算符");
            string oper = Console.ReadLine();
            Console.WriteLine("请输入第二个数");
            string v2 = Console.ReadLine();
            ICalculatable calculatable = Factory.GetCalculatableByOper(oper).GetCalculatable();
            Console.WriteLine("结果：" + calculatable.GetReslut(Convert.ToDouble(v1), Convert.ToDouble(v2))); 
            #endregion

      注意：此处的判断逻辑已经不属于工厂模式了（类图中很明确），也可以脱离客户端。虽说简单工厂也可以这样将判断逻辑脱离客户端，但是简单工厂的逻辑判断是在工厂类中的，也就依然是简单工厂模式的一部分（此处逻辑有些乱，不懂的就认真研究类图）。通常在工厂模式的客户端需要用到哪种工厂再去创建哪种工厂，而不是如例子中的使用一个判断逻辑来选择，也就是工厂模式创建工厂是通过“外部”的逻辑来确定，而模式本身是不会做判断的。（所以这个例子并不是一个合适的例子）

      此时，计算器要再添加一个开方的方法，只需添加方法实现，添加工厂实现，不会对原有的代码做修改，符合了开闭原则（你当我瞎啊，你不修改判断逻辑吗？说了多少次了，判断逻辑部分不属于工厂模式。不过比简单工厂确实多写不少东西）。

      工厂方法模式通常在以下两种情况中使用 :

      第一，需要使用某种产品,客户端很清楚应该使用哪个具体工厂，此种情况不存在上述的判断逻辑，只需要实例化具体工厂，然后生产具体产品。

      第二，需要使用某种产品，但是不想也不需要知道是哪个工厂创建，此种情况存在一定的判断逻辑，但是客户端不需要知道这个逻辑，生产方（工厂模式）是通过外部的逻辑来生产产品，这时由外部来实例化具体工厂，生产具体产品交付给客户端。

      接着再来说说抽象工厂，在抽象工厂中最明显的一个特点是产品不止一类了，所以前文提到的计算机的例子就不适合使用抽象工厂模式（窃以为如此，有反对意见的欢迎提出）。

      在抽象工厂在提到一个“产品族”的概念，其实在抽象工厂中最为直观的体现就是产品A接口，产品B接口甚至是产品C、D接口。类图如下，从类图中不难发现，抽象工厂模式的具体工厂角色可以生产多种产品（工厂方法模式的具体工厂只能生产一种产品，不信去看类图）。就好像东方红拖拉机厂在工厂方法模式下只能生产拖拉机，但是在抽象工厂模式下不仅能生产拖拉机，还能生产卡车（如果加一个坦克的生产线，还能生产坦克）。

      此处就用比较熟悉的农场的例子，农场生产水果和蔬菜，水果分为北方水果和热带水果，蔬菜也一样，所以农场也分为北方农场和热带农场。

      代码如下：

    public interface IFruit
    {
        string Show();
    }

    public interface IVeggie
    {
        string Show();
    }

    public class NFruit : IFruit
    {
        private string name;
        public string Name
        {
            get { return "北方" + name; }
            set { name = value; }
        }

        public string Show()
        {
            return Name;
        }
    }

    public class TFruit : IFruit
    {
        string name;

        public string Name
        {
            get { return "热带" + name; }
            set { name = value; }
        }

        public string Show()
        {
            return Name;
        }
    }

    public class NVeggie : IVeggie
    {
        string name;

        public string Name
        {
            get { return "北方" + name; }
            set { name = value; }
        }


        public string Show()
        {
            return Name;
        }
    }

    public class TVeggie : IVeggie
    {
        string name;

        public string Name
        {
            get { return "热带" + name; }
            set { name = value; }
        }

        public string Show()
        {
            return Name;
        }
    }

    public interface Factory
    {
        IFruit CreateFruit(string nm);
        IVeggie CreateVeggie(string nm);
    }

    public class NFactory : Factory
    {
        public IFruit CreateFruit(string nm)
        {
            return new NFruit() { Name = nm };
        }

        public IVeggie CreateVeggie(string nm)
        {
            return new NVeggie() { Name = nm };
        }
    }

    public class TFactory : Factory
    {
        public IFruit CreateFruit(string nm)
        {
            return new TFruit() { Name = nm };
        }

        public IVeggie CreateVeggie(string nm)
        {
            return new TVeggie() { Name = nm };
        }
    }

      此例的逻辑判断部分没写。从类图上看，它是不属于抽象工厂模式的，从简化客户端的角度，这个逻辑判断是可以从客户端剥离的，很显然和工厂方法模式的逻辑判断属于同一地位（有种两头受气的感觉）。

     然后再简单说spring的依赖注入。在spring中需要获取一个产品（实例）如何获取？容器来提供。逻辑判断呢？可以放在客户端，也可以从客户端剥离，爱放哪放哪。容器只依赖于配置，逻辑判断不会影响容器。所以容器很好的将生产过程与客户端隔离，这就不存在耦合了。

      接下来再说一下，一直不停的重复的判断逻辑。在菜鸟D 的看法里，上述几个模式的耦合都是存在于判断逻辑中的。在简单工厂中，工厂和客户端之间耦合较低，但是工厂和具体的产品类是直接耦合的。在工厂方法模式、抽象工厂模式、spring中，逻辑判断只是一个辅助，逻辑判断将生产过程和客户端隔离，大大地降低了耦合程度。所以在衡量设计模式的耦合时，就需要衡量判断逻辑在模式中作用和角色。有些耦合是很难避免的，为了避免这些耦合甚至可能会造成更多的耦合。至于开闭原则，编码过程尽量去注意，否则为以后的开发带来麻烦就不是我们想要的了。

     一家之言，不值一哂，如有谬误，欢迎指正。

     菜鸟D希望这篇文章对您有所帮助。

扩展参考：

大话设计模式P72:

      工厂方法实现时,客户端需要决定实例化哪一个工厂来实现运算类(具体产品),选择判断的问题还是存在的,也就是说,工厂方法吧简单工厂的内部逻辑判断移到了客户端代码来进行.想要添加功能,本来是要改工厂类的,而现在是修改客户端.

三种工厂模式区别总结

http://blog.csdn.net/lingfengtengfei/article/details/12374469

spring.net的依赖注入

http://www.cnblogs.com/GoodHelper/archive/2009/10/26/SpringNET_DI.html

工厂方法模式

http://blog.csdn.net/zhengzhb/article/details/7348707

三种工厂模式

http://www.cnblogs.com/poissonnotes/archive/2010/12/01/1893871.html