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

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

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

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

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值