从一个计算器开始提及——C#中的工厂方法模式

时间 2020-06-19

标签一个计算器开始提及 c# 工厂方法模式栏目 C# 繁體版

原文原文链接

工厂模式做为很常见的设计模式，在平常工做中出镜率很是高，程序员们必定要掌握它的用法哟，今天跟着老胡一块儿来看看吧。git

举个例子

如今先让咱们来看一个例子吧，好比，要开发一个简单的计算器，完成加减功能，经过命令行读入形如1+1的公式，输出2这个结果，让咱们看看怎么实现吧。程序员

第一个版本

这个版本里面，咱们不考虑使用模式，就按照最简单的结构，怎么方便怎么来。设计模式

思路很是简单，仅须要实现如下几个方法框架

取运算数
取运算符
输出结果

class Program
    {
        static int GetOperatorIndex(string input)
        {
            int operatorIndex = 0;
            for (; operatorIndex < input.Length; operatorIndex++)
            {
                if (!char.IsDigit(input[operatorIndex]))
                    break;
            }
            return operatorIndex;
        }

        static int GetOp(string input, int startIndex, int size = -1)
        {
            string subStr;
            if (size == -1)
            {
                subStr = input.Substring(startIndex);
            }
            else
            {
                subStr = input.Substring(startIndex, size);
            }
            return int.Parse(subStr);
        }

        static int CalculateExpression(string input)
        {
            var operatorIndex = GetOperatorIndex(input); //获得运算符索引
            var op1 = GetOp(input, 0, operatorIndex); //获得运算数1
            var op2 = GetOp(input, operatorIndex + 1); //获得运算数2
            switch (input[operatorIndex])
            {
                case '+':
                    return op1 + op2;
                case '-':
                    return op1 - op2;
                default:
                    throw new Exception("not support");
            }
        }

        static void Main(string[] args)
        {
            string input = Console.ReadLine();
            while(!string.IsNullOrEmpty(input))
            {
                var result = CalculateExpression(input);
                Console.WriteLine("={0}", result);
                input = Console.ReadLine();
            }            
        }
}

代码很是简单，毋庸置疑，这个运算器是能够正常工做的。这也多是咱们大部分人刚刚踏上工做岗位的时候可能会写出的代码。但它有着如下这些缺点：编码

缺少起码的抽象，至少加和减应该能抽象出操做类。
缺少抽象形成了巨型客户端，全部的逻辑都嵌套在了客户端里面。
使用switch case缺少扩展性，同时switch case也暗指了这部分代码是属于变化可能性比较高的地方，咱们应该把它们封装起来。并且不能把他们放在和客户端代码一块儿

接下来，咱们引入咱们的主题，工厂方法模式。
命令行

工厂方法模式版本

工厂方法模式使用一个虚拟的工厂来完成产品构建（在这里是运算符的构建，由于运算符是咱们这个程序中最具备变化的部分），经过把可变化的部分封装在工厂类中以达到隔离变化的目的。咱们看看UML图：

依葫芦画瓢，咱们设计思路以下：设计

设计一个IOperator接口，对应抽象的Product
设计AddOperator和SubtractOperator，对应具体Product
设计IOperatorFactory接口生产Operator
设计OperatorFactory实现抽象IFactory

关键代码以下，其余读取操做数之类的代码就不在赘述。code

IOperator接口

interface IOperator
       {
           int Calculate(int op1, int p2);
       }

具体Operator

class AddOperator : IOperator
        {
            public int Calculate(int op1, int op2)
            {
                return op1 + op2;
            }
        }

        class SubtractOperator : IOperator
        {
            public int Calculate(int op1, int op2)
            {
                return op1 - op2;
            }
        }

Factory接口

interface IOperatorFactory
        {
            IOperator CreateOperator(char c);
        }

具体Factory

class OperatorFactory : IOperatorFactory
        {
            public IOperator CreateOperator(char c)
            {
                switch(c)
                {
                    case '+':
                        return new AddOperator();
                    case '-':
                        return new SubtractOperator();
                    default:
                        throw new Exception("Not support");
                }
            }
        }

在CalculateExpression里面使用他们

static IOperator GetOperator(string input, int operatorIndex)
       {
           IOperatorFactory f = new OperatorFactory();
           return f.CreateOperator(input[operatorIndex]);
       }

       static int CalculateExpression(string input)
       {
           var operatorIndex = GetOperatorIndex(input);
           var op1 = GetOp(input, 0, operatorIndex);
           var op2 = GetOp(input, operatorIndex + 1);
           IOperator op = GetOperator(input, operatorIndex);
           return op.Calculate(op1, op2);                    
       }

这样，咱们就用工厂方法从新写了一次计算器，如今看看，好处有blog

容易变化的建立部分被工厂封装了起来，工厂和客户端以接口的形式依赖，工厂内部逻辑能够随时变化而不用担忧影响客户端代码
工厂部分能够放在另一个程序集，项目规划会更加合理
客户端仅仅须要知道工厂和抽象的产品类，不须要再知道每个具体的产品（不须要知道如何构建每个具体运算符），符合迪米特法则
扩展性加强，若是以后须要添加乘法multiple，那么仅须要添加一个Operator类表明Multiple而且修改Facotry里面的生成Operator逻辑就能够了，不会影响到客户端

自此，咱们已经在代码里面实现了工厂方法模式，但可能有朋友就会想，虽然如今扩展性加强了，可是新添加运算符仍是须要修改已有的工厂，这不是违反了开闭原则么。。有没有更好的办法呢？固然是有的。
索引

反射版本

想一想工厂方法那个版本，咱们为何增长新的运算符就会不可避免的修改现有工厂？缘由就是咱们经过switch case来硬编码“教导”工厂如何根据用户输入产生正确的运算符，那么若是有一种方法可让工厂自动学会发现新的运算符，那么咱们的目的不就达到了？

嗯，我想聪明的朋友们已经知道了，用属性嘛，在C#中，这种方法完成类的自描述，是最好不过了的。

咱们的设计思路以下：

定义一个描述属性以识别运算符
在运算符中添加该描述属性
在工厂启动的时候，扫描程序集以注册全部运算符

代码以下：

描述属性

class OperatorDescriptionAttribute : Attribute
    {
        public char Symbol { get; }
        public OperatorDescriptionAttribute(char c)
        {
            Symbol = c;
        }
    }

添加描述属性到运算符

[OperatorDescription('+')]
    class AddOperator : IOperator
    {
        public int Calculate(int op1, int op2)
        {
            return op1 + op2;
        }
    }

    [OperatorDescription('-')]
    class SubtractOperator : IOperator
    {
        public int Calculate(int op1, int op2)
        {
            return op1 - op2;
        }
    }

让工厂使用描述属性

class OperatorFactory : IOperatorFactory
    {
        private Dictionary<char, IOperator> dict = new Dictionary<char, IOperator>();
        public OperatorFactory()
        {
            Assembly assembly = Assembly.GetExecutingAssembly();
            foreach (var type in assembly.GetTypes())
            {
                if (typeof(IOperator).IsAssignableFrom (type) 
                    && !type.IsInterface)
                {
                    var attribute = type.GetCustomAttribute<OperatorDescriptionAttribute>();
                    if(attribute != null)
                    {
                        dict[attribute.Symbol] = Activator.CreateInstance(type) as IOperator;
                    }
                }
            }
        }
        public IOperator CreateOperator(char c)
        {
            if(!dict.ContainsKey(c))
            {
                throw new Exception("Not support");
            }
            return dict[c];
        }
    }

通过这种改造，如今程序对扩展性支持已经很友好了，须要添加Multiple，只须要添加一个Multiple类就能够，其余代码都不用修改，这样就完美符合开闭原则了。

[OperatorDescription('*')]
  class MultipleOperator : IOperator
  {
      public int Calculate(int op1, int op2)
      {
          return op1 * op2;
      }
  }

这就是咱们怎么一步步从最原始的代码走过来，一点点重构让代码实现工厂方法模式，最终再完美支持开闭原则的过程，但愿能帮助到你们。

其实关于最后那个经过标记属性实现扩展，微软有个MEF框架支持的很好，原理跟这个有点类似，有机会咱们再聊聊MEF。