coupling, 即两个东西之间的一种连接,使他们彼此关联。
以前大学里学软件工程和面向对象的时候,就时常听到解耦和低耦合,所以现在在做开发的时候,也往往会去想,怎么降低耦合度呢。
软件工程书籍中,这么写道,高内聚及低耦合可以给我们软件开发人员带来可读性、复用性、可维护性和易变更性。
耦合天成
软件开发过程中,耦合是不可避免的,除非做出来一个超级巨大,包含一切功能的类/模块,都放在里面做(这显然并不是高内聚,只是把乱七八糟的揉在一起),否则模块与模块之间必然存在一定的耦合。
既然耦合不可避免,那高耦合和低耦合,又会对开发和维护产生什么影响呢?
高耦合,也就意味着两者之间存在强的关联,比如强持有、双向依赖、多个变量/常量的互相访问,如此也就造成其中一个需要更改的时候,另一个类也需要大量更改,而在Runtime的领域,则可能发生其中一个导致另一个不能释放。尤其实际生产过程中,往往不只是两个类有耦合关系,会有更多的类,从而产生一条耦合链。
低耦合,即两者之间关联较弱,比如广播,dataflow架构,单向单依赖等等。组合优于继承这个说法,也是从业务模型的角度,组合有时候相对于继承降低了耦合。
耦合的代价
高耦合的代价,从开发人员角度来说,会导致
维护困难:因为各种逻辑揉在一起,互相之间依赖来依赖去,查问题的时候很难定位。
变更困难:由于关联太强,修改一个小需求却要改很多逻辑
难以复用:新开发的功能用到了相同的逻辑,但是只能复制黏贴过去。比较常见的一个例子就是应该在utils里的东西却在业务代码里。
可读性差:过一阵子自己看,或者换了负责人员后,很难读懂原来的逻辑
低耦合的代价,则可能会需要付出性能、代码行数、更多的时间去设计和解耦。
点击查看更多内容
为 TA 点赞
评论
共同学习,写下你的评论
评论加载中...
作者其他优质文章
正在加载中
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦