L 的专栏

记录有价值的事, 回忆开心的点滴!

为什么使用反射机制解决系统耦合是误用.

先前发了一个帖关于反对将 反射机制 作为解决系统耦合问题的文章. 现在就来谈谈为什么反对这个观点.

反射机制是一个非常强大的功能, 其在对于动态调用对象和对象方法上具有不可替代的作用. 同时其具有很强的灵活性, 给于了编码者最大程度的可操作性. 但正是其强大的灵活性决定了其不能成为模块间卸耦的解决方案, 更不能成为系统间的卸耦方案. 想想看, 一个模块 A 所需要的另外一个模块 B, 通过反射机制, 一般就是直接通过类名, 方法名 和 属性名对其进行操作, 而这些 String 是没有任何限制机制的. 也就说, 对于 B 改变了方法名, A 是没有任何异象的. 那么A还是可以编译通过. 但是运行时, 其就可能遇到找不类, 方法或者Field 等异常. 这样的不确定性, 在模块间是绝对不能出现的.

 <反射机制与系统耦合实例详解> 作者举的例子只能说明 通过接口来固定模块的行为. 但此方法已经不是通过反射机制卸耦了(原作者始终认为这个是通过反射机制达到卸耦的).  依赖注入更是基于接口的一个非常好的方案, 但是这更是跟通过反射机制解决系统耦合不相关了.  

阅读更多
文章标签: string
上一篇用 C语言 的将继续保持沉默. 呵呵
下一篇Map.containsKey() 的一个使用场景.
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭