IOC演义1

开篇按语

洪荒少女傅园慧以其丰富的表情包和夸张的语言瞬间征服了全世界，赢得了比大多数冠军还高的关注度。这充分说明了仅仅有实力是不够的，还要有必要的营销手段。

每个人都有不同程度的武侠梦想和江湖情节，下面我们就以宏大的NET Framwork世界为背景，以c#为武器，看一个无名小辈如何炼成了名震江湖的编码大侠。

必备技能

想要在江湖扬名立万，自然要有两把刷子，这里要求你能够看懂c#（java也没问题，二者简直是同卵双胞胎）源代码，知道泛型、反射和弱引用的使用，当然还有单元测试。这是一个设计IOC框架的故事，所以什么是IOC和最佳拍档AOP你最好也了解一些，面向接口编程这样高端大气上档次的东西也需要知道。重构作为码农的基本功，是必须掌握的，你完全可以把这篇文章看做重构的教程，可以根据行文自己重构一下，然后对比看看二者的异同。

行走江湖，不免要展示自己的能力。如果只是欺负一些无名小辈和普通百姓，最多只能成为镇关西和南霸天这样的地痞，不可能成为名震江湖的大侠。而向有头脸的腕主们挑战或者征服、消灭前面的地痞无疑是展示武功的绝佳途径。下面开始我们的征服之旅：

正式开始

作为练手升级的第一站，自然要挑软柿子捏，下面就是我们需要征服的目标，非常简单，表示人相关信息的类：

普通类的属性一般是这样定义的：

public interface IPerson {

  string Name { get; set; }

  int Age { get; set; }

}

internal class Person : IPerson {

  public string Name { get; set; }

  public int Age { get; set; }

}

internal class Person1 : IPerson {

  private string name;

  private int age;

  public string Name

  {

    get { return name; }

    set { name = value; }

  }

  public int Age

  {

    get { return age; }

    set { age = value; }

  }

}

上面两个版本的本质完全一样，前者为后者的“语法糖”；而第二个实现更接近本质，我们就以后者为蓝本开始本次的发现之旅。

开发需求

（需要说明，这里仅仅出于演示目的而没有考虑是否合理，另外在平时如果不需要我们后面添加的功能，而仅仅储存相关数据，使用上面定义已经足够快捷和好用，不需要画蛇添足）。我们看看这个类的实例都有什么能力:

[TestClass]

public partial class PersonTest {

  [TestMethod]

  public void TestSample1() {

    IPerson p = new Person1();

    Assert.AreEqual(p.Age, default(int));

    TestPersion(p);

  }

  private void TestPersion(IPerson p) {

    Assert.AreEqual(p.Name, default(string));

    p.Name = "aa";

    p.Age = 1000;

    Assert.AreEqual(p.Name, "aa");

    Assert.AreEqual(p.Age, 1000);

  }

}

很简单，没有为属性赋值的时候返回缺省值；赋值以后就储存在字段里面，需要则返回储存的新值。这里出头露面的属性Name实际仅仅是个马仔和提线木偶，它是什么值不由自己决定，而是由它后面的大哥name字段决定，因此征服了大哥name（这个大哥也太寒酸了，仅仅控制了一个小弟）也就征服了属性Name；其他属性同理。

一统小孤山

经过血雨腥风、不眠不休、遇神杀神、遇佛杀佛、大战三百合后（……此处省略300字，没办法，功力浅，碰到蚂蚁都要踩三脚才能干掉），我们征服了所有的大哥，把这些字段收降在一个宝袋（集合）里面，这样就可以用这个集合取代这一群字段，因为这些字段的类型和名称五花八门，这个集合的类型自然是它们的共同祖先：object类型了；而原来不同的字段名称也统一在集合的名下，也就是集合成为了这群属性的老大（众属性高呼：老大威武，老大万岁）。当然了，对字段的操作也需要相应转换为对集合的操作。想想秦始皇统一全中国干的不就是类似的事情吗？

internal class Person2 : IPerson {

  private string a;

  private int b;

  private object[] backFields = { null, 0 };

  public string Name

  {

    get { return name; }

    set { name = value; }

    get { return (string)backFields[0]; }

    set { backFields[0] = value; }

  }

  public int Age

  {

    get { return salay; }

    set { salay = value; }

    get { return (int)backFields[1]; }

    set { backFields[1] = value; }

  }

}

public partial class PersonTest {

  [TestMethod]

  public void TestSample2() {

    TestPersion(new Person2());

  }

}

需要说明，因为泯灭了原来字段的个性（字段类型统一为object），现在的属性出现了磨洋工的情形（值类型对象转换为object后在读写时需要装箱和拆箱操作，这会导致其性能降低）。这是没有办法的事情，统一也是有代价的，这是我们必须承受的代价。另外和后面的收获相比，这点代价也是微不足道的。

此正是：昔日秦皇灭六国 是非功过后人说 今天寄出大杀器 只用欧不接可特（object）

 初步优化，使用字典

我们比较两个版本中不同属性定义代码的差异，由需要修改两处变为了3处：分别是返回的强制转换类型和两处数组索引。前者的类型和属性的类型一致或兼容，后者由变量名改为了数字。也就是修改的内容都是符合逻辑的，还去掉了一堆的字段定义，就算扯平了或者小输吧。在集合里面仅仅保存了属性的值，而没有其他信息，导致我们需要与属性对应的时候必须根据属性里面的索引来推测；另外如果添加属性还需要添加对应的默认值，这太不方便了。怎么办？嗯，属性名称和对应值保存在一个字典里面是个不错的主意。下面我们小小修改一下：

internal class Person2A : IPerson {

  private object[] backFields = { null, 0 };

  private Dictionary<string, object> backFields = new Dictionary<string, object>();

  public string Name

  {

    get { return (string)backFields[nameof(Name)]; }

    set { backFields[nameof(Name)] = value; }

  }

  public int Age

  {

    get { return (int)backFields[nameof(Age)]; }

    set { backFields[nameof(Age)] = value; }

  }

}

public partial class PersonTest {

  [TestMethod]

  [ExpectedException(typeof(KeyNotFoundException))]

  public void TestSample2A() {

    TestPersion(new Person2A());

  }

}

用属性名称代替数字无疑直观了许多，也弥补了收编大哥的部分自尊心：有名字的教师爷或武师，毕竟还是比仅有编号9527的奴才地位高一些的。在以后查询的时候直接查看集合就知道所有属性和对应的值了。

 回头审视，修改错误

针对上面存在的问题,继续我们修改和优化旅程：我们把集合修改为字典，初始状态为空，不像上面数组版本里面保存了各个属性对应的缺省值。这样就引入了bug：字典里面没有保存值的时候返回和修改属性值都会引发异常。我们先封装操作字典的方法，然后在这些方法里面修改：

internal class Person3 : IPerson {

  public string Name

  {

    get { return (string)Get(nameof(Name)); }

    set { Set(nameof(Name), value); }

  }

  public int Age

  {

    get { return (int)Get(nameof(Age)); }

    set { Set(nameof(Age), value); }

  }

  private Dictionary<string, object> backFields = new Dictionary<string, object>();

  private void Set(string name, object value) {

    if (backFields.ContainsKey(name))

      backFields[name] = value;

    else

      backFields.Add(name, value);

  }

  private object Get(string name) {

    if (backFields.ContainsKey(name))

      return backFields[name];

    return null;

  }

}

public partial class PersonTest {

  [TestMethod]

  public void TestSample3() {

    TestPersion(new Person3());

  }

}

这个版本比上面的多了两个方法，分别用于对集合的读写操作。管理这些属性的老大也仅仅在这里露下面，这样当我们需要添加其他功能（比如通知）或者出问题的时候在这里修改一下就可以了。（注意get的最后一句，又引入了bug，你知道吗？）

每个属性保存两个信息：属性名称和属性值，比起数组版本似乎还浪费了空间。其实不一定，这个字典集合在没有修改属性前是空的，其内容随着修改属性的个数而增加。这在有很多属性（比如常用的控件最少都有几十个属性）的情形下，反而是节省了不少的空间。

修改到这里其实已经与第一个版本有了质的不同。不过这个字典老大只能管理一个实例对象，如果生成了100个对象，就有100个同样的老大，又出现了前面类似管理大哥的问题。怎么办？为了更方便管理，我们请一位总管来管理这些老大，而我们只需要控制这个总管就可以了。按照上面的思路，我们的总管需要管理实例和对应的全部属性，字典那是必须的。

继续优化，初露端倪

提示：到了这里，我们其实有必要把集合与对应的操作方法移到公共类里面，作为所有对象的公共容器。不过还需要一些修改进化，现在总管集合还是暂时寄居在这里，但是修改为了static（静态成员表示此成员不是某个实例所有，而是所有实例公有），也就是有了公共容器的性质：

internal class Person4 : IPerson {

  public string Name

  {

    get { return (string)Get(this, nameof(Name)); }

    set { Set(this, nameof(Name), value); }

  }

  public int Age

  {

    get { return (int)Get(this, nameof(Age)); }

    set { Set(this, nameof(Age), value); }

  }

  public static Dictionary<object, Dictionary<string, object>> Containor =

    new Dictionary<object, Dictionary<string, object>>();

  public static void Set(object instance, string name, object value) {

    var backFields = new Dictionary<string, object>();

    if (Containor.ContainsKey(instance))

      backFields = Containor[instance];

    else

      Containor.Add(instance, backFields);

    if (backFields.ContainsKey(name))

      backFields[name] = value;

    else

      backFields.Add(name, value);

  }

  public static object Get(object instance, string propertyName) {

    var backFields = new Dictionary<string, object>();

    if (Containor.ContainsKey(instance))

      backFields = Containor[instance];

    if (backFields.ContainsKey(propertyName))

      return backFields[propertyName];

    return null;

  }

}

public partial class PersonTest {

  [TestMethod]

  public void TestSample4() {

    TestPersion(new Person4());

  }

}

进行到这里，我们获得了一个相对稳定的容器类，而实际的Sample类里面属性的方法体使用传统的强类型方法已经无法修改，也就是到达极限了。这样不同属性代码之间的差异有三处。也就是如果添加新属性，除了名称外，需要修改3个地方。这太繁琐了。为了减少修改量，我们使用反射试试：

反射参与，绝路变坦途

（提示：反射是威力巨大的大杀器，与战呼局张局并列4大神器。小伙子，一般人我不告诉他，看你根骨神奇，是编程的奇才，将来编程世界的统一就靠你了。这本反射秘籍10块给你，怎么样？）

internal class Person5 : IPerson {

  public string Name

  {

    get

    {

      var mi = MethodBase.GetCurrentMethod() as MethodInfo;

      return (string)Get(this, mi);

    }

    set

    {

      var mi = MethodBase.GetCurrentMethod() as MethodInfo;

      Set(this, mi, value);

    }

  }

  public int Age

  {

    get

    {

      var mi = MethodBase.GetCurrentMethod() as MethodInfo;

      return (int)Get(this, mi);

    }

    set

    {

      var mi = MethodBase.GetCurrentMethod() as MethodInfo;

      Set(this, mi, value);

    }

  }

  public static Dictionary<object, Dictionary<string, object>> Containor =

    new Dictionary<object, Dictionary<string, object>>();

  public static void Set(object instance, MethodInfo methodInfo, object value) {

    var name = GetPropertyName(methodInfo);

    var backFields = new Dictionary<string, object>();

    if (Containor.ContainsKey(instance))

      backFields = Containor[instance];

    else

      Containor.Add(instance, backFields);

    if (backFields.ContainsKey(name))

      backFields[name] = value;

    else

      backFields.Add(name, value);

  }

  private static string GetPropertyName(MethodInfo methodInfo) {

    var name = methodInfo.Name;

    name = name.Substring(4, name.Length - 4);

    return name;

  }

  public static object Get(object instance, MethodInfo methodInfo) {

    string propertyName = GetPropertyName(methodInfo);

    var backFields = new Dictionary<string, object>();

    if (Containor.ContainsKey(instance))

      backFields = Containor[instance];

    if (backFields.ContainsKey(propertyName))

      return backFields[propertyName];

    return null;

    if (methodInfo.ReturnType.IsValueType)

      return Activator.CreateInstance(methodInfo.ReturnType);

    return null;

  }

}

public partial class PersonTest {

  [TestMethod]

  public void TestSample5() {

    TestPersion(new Person5());

  }

}

这样修改以后类的代码变多了，但是在属性里面代码需要修改的地方却减少了；或者说，不同属性代码的相似度提高了，添加新属性的时候需要修改的地方就少了。我们看看不同属性的代码，除了get代码里面的return语句的强制转换类型不一样，其他完全相同。据我夜观天象，这一处修改是胎里带的缺陷，不管使用什么方法都去不掉的，大罗神仙来了也没用。

另外传入的名称参数改为了传入方法信息，因为它不仅仅携带了方法的名称信息，还携带了定义类型的信息，这样就方便我们顺手消除了一个bug。

修改到这里，基本到达我们的要求，而一个新的类也应该诞生了；同时考虑操作对象的方法：Get和Set，前者的参数要比后者少一个，另外方法信息里面的方法名称也有get和set字符串，因此就没有必要利用名称区分了；再考虑到属性信息不但携带了属性名称，还带有属性类型等等其他信息，使用它做键比属性名称好多了；最后，存放在这个容器里的对象为强引用，当其他地方都不再引用某个对象而应该被回收时，却因为这里的引用而不能被回收显然是不合理的，顺手修改一下上面存在的问题。

小结：

本文使用不同的思路，以适用为导向，用幽默风趣的语言，从一个普通的数据类作为起始点，一步一步修改，最后形成一个框架的雏形。为后面的演绎拉开了序幕……

结语

你看我嘚啵了大半天，肚子也咕咕叫了，你们谁请我吃顿饭……哎哎……别走呀，各位，怎么一到关键时候就掉链子？说你呢，还笑……不请吃饭就算了，点个赞，回个支持，这点小小的要求不过分吧？（此处应该有掌声）

此正是：秦皇汉武功德高 一统天下胆气豪 依赖注入掀巨浪 斩断一切紧藕合  

预知今天最终版本如何，请听下回分解：

互动问题：

1：大哥、老大、总管各有什么功能？

2：你觉得这几个版本哪两个之间的跨度最大？最有意义？哪个版本最糟糕？

3：总管是字典，每条记录都储存了什么信息？

4、中午饭谁请？

IOC演义1