你什么时候用反射？模式/反模式

我理解反射API(在c#中),但我不确定在什么情况下我会使用它.有哪些模式 - 使用反射的反模式？

在我正在研究的一种产品中,我们经常使用它,但是反射是一种复杂,缓慢的野兽.不要因为听起来很有趣或有趣而去寻找使用它的地方.当您遇到无法以任何其他方式解决的问题时,您将使用它(为插件或框架动态加载程序集,程序集检查,在构建时不知道类型的工厂等).当然值得一看反思教程,看看它是如何工作的,但不要陷入"有锤子,一切看起来像钉子"的陷阱.它有非常专业的用例.

我在C#中使用Reflection内容的唯一地方是工厂模式,我根据配置文件信息创建对象(在我的例子中是网络侦听器).配置文件提供了程序集的位置,其中类型的名称以及所需的任何其他参数.工厂挑选了这些东西并根据它创建了听众.

我不知道它是否是一个模式,但我使用反射从DAO的类定义生成SQL.

我曾在很多地方使用过反射.主要的广泛类别包括:

自动生成的GUI(即属性编辑器).您可以遍历对象的属性并使用UI元素工厂的注册表来构建表单.我使用属性上的属性来指导UI创建.

序列化.我编写了序列化框架,使用反射来序列化和反序列化对象.

网络服务.与序列化类似,我使用反射来创建和使用SOAP消息,并生成WSDL.

领域特定语言.解释的脚本语言通常使用反射绑定到对象和方法.

调试工具.这些工具可以使用反射来检查对象的状态.方便在故障条件下创建日志消息.

模式明智,我不确定模式是什么.所有用法之间的共同线程是名称引用和后期绑定 - 您希望在运行时绑定到成员.当您动态加载程序集并且不知道需要创建/操作的目标类型时,通常会出现这种情况.

使用反射是强大的,但它不会让你在派对上更受欢迎.仅在耦合故意弱的地方使用.如此虚弱,以至于你希望它在运行时中断.一个很好的例子是WPF中的数据绑定.

我不确定反模式,但肯定会与在运行时做的事情有关,应该在编译时完成...

没有硬性规定.基本上,你没有充分的理由不使用反射.如果没有它就无法做你想做的事情,或者你的代码在没有反思的情况下会更长或更难理解的情况下使用反射.

我发现反射(结合运行时类加载)对于实现插件是必不可少的:

在已知位置搜索罐子/组件

为支持插件支持的接口的类枚举jar/assembly

在运行时实例化插件