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

本文探讨了为何反射机制不适合作为解决系统耦合问题的方法。通过分析反射机制的特点和灵活性,指出其在模块间卸耦时可能导致的不确定性问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

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

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值