Effective C# 原则43：请勿滥用反射

核心提示： 如果你用标记了特性的类厂函数来合并接口，几乎所有的你所期望于反射的解决方案都变得更简单：public class MyType : IMyInterface{[FactoryFunction]public static IMyInterfaceCreateInstance( ){retur

如果你用标记了特性的类厂函数来合并接口，几乎所有的你所期望于反射的解决方案都变得更简单：

public class MyType : IMyInterface
{
　[FactoryFunction]
　public static IMyInterface
　　CreateInstance( )
　{
　　return new MyType( );
　}
　#region IMyInterface
　public string Msg
　{
　　get
　　{
　　　return _msg;
　　}
　　set
　　{
　　　_msg = value;
　　}
　}
　public void DoWork( )
　{
　　// details elided.
　}
　#endregion
}

把这段代码与前面的基于反射的方案进行对比。即使这只是简单的例子，但还有在某些弱类型上使用所有的反射API时有精彩之处：返回类型已经是类型化的对象。而在反射上，如果你想取得正确的类型，你须要强制转换。这一操作可能失败，而且在继承上有危险。而在使用接口时，编译器提供的强类型检测显得更清楚而且更易维护。

反射应该只在某些调用目标不能清楚的用接口表示时才使用。.Net的数据绑定是在类型的任何公共属性上可以工作，把它限制到定义的接口上可能会很大程度上限制它的使用。菜单句柄的例子充许任何函数(不管是实例的还是静态的)来实现命令句柄，使用一个接口同样会限制这些功能只能是实例方法。FxCop 和NUnit (参见原则48)都扩展了反射的使用，它们使用反射，是因为它们遇到的的现实的问题是最好用它来处理的。FxCopy 检测所有的代码来评估它们是否与已经的原则矛盾。这须要使用反射。NUnit 必须调用你编译的测试代码。它使用反射来断定哪些你已经写的代码要进行单元测试。对于你可能要写的测试代码，可能是一个方法集合，但接口是不能表达它们的。NUnit使用特性来发现测试以及测试案例来让它的工作更简单(参见原则42)。

当你可以使用接口策划出你所期望调用的方法和属性时，你就可以拥有一个更清楚，更容易维护的系统。反射是一个在数据以后绑定上功能强大的工具。.Net框架使用它实现对Windows控件和Web控件的数据绑定。然而，很多常规情况下很少用，而是使用类厂，委托，以及接口来创建代码，这可以产生出更容易维护的系统。