简单工厂模式,工厂方法模式,抽象工厂模式,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