C#动静结合编程之三：Duck Typing

核心提示：中庸C#是静态类型语言，要使用类型必须引用该类型的定义，C#动静结合编程之三：Duck Typing，因此，从软件组织角度会发生组件间的引用依赖关系，又能享受IDE智能提示和编译器检查（签名检查）等好处，因此，常见的引用依赖关系有两种模式：a. 正向依赖：组件A用到了组件B中定义的类T，组件A直接引用组件B

中庸

C#是静态类型语言，要使用类型必须引用该类型的定义。因此，从软件组织角度会发生组件间的引用依赖关系。常见的引用依赖关系有两种模式：

a. 正向依赖：组件A用到了组件B中定义的类T，组件A直接引用组件B，依赖关系是“组件A -> 组件B”。

b. 反向依赖：组件A通过接口I定义功能规范，针对抽象编程；组件B反过来引用组件A，并定义类T实现接口I；由另一组件C将I与T粘合起来，依赖关系是“组件A <- 组件B”。这就是著名的IoC方式。

简单说来，IoC是“谁制定规范，谁就拥有控制权；谁执行规范，谁就被控制”。如果规范借助于C#的静态类型检查，比如接口或抽象类，那么规范就表现出较强的语法约束性，使得组件A的编写比较独立，而组件B则受制与组件A。

本系列的第一篇举了一个基于接口的IoC例子，我们看到当需要采用第三方组件时，为了适用接口的静态类型约束，不得不增加一个adapter去实现接口并包装对第三方组件的调用。这表现出基于接口的IoC在粘合规范与实现时不太灵活。

但是，规范和类型约束没有必然的联系。在基于委托的IoC例子中，我们不需要任何的adapter，就能轻松的粘合规范与实现，表现出较强的灵活性。这就是通过委托定义规范，不会造成组件B对组件A的依赖，组件A和组件B的实现都显得比较独立。

实际上，我们还可以有比委托更灵活的规范表达方式，比如：通过HTTP + XML来表达规范，这样甚至是语言无关的，完全可能组件A由C#编写，组件B由Java编写。

上面列举的3种规范定义方式：基于接口、基于委托、基于HTTP + XML分别代表了由约束到协议，由严格到灵活的3种风格。当然，还有更多的方式，但这里只列举这三种作为代表。动与静之间需要把握一个分寸，接口过于死板；而HTTP + XML的方式则完全是基于运行时协议的，需要自己做很多检查工作；委托的好处在于既消除了组件A、B的依赖关系，又能享受IDE智能提示和编译器检查（签名检查）等好处。因此，委托是把动与静结合得恰到好处的中庸之道。