2021-09-05 20:54  阅读(333)
文章分类:设计原则 文章标签:设计原则
©  原文作者:Demo_Null 原文地址:https://cloud.tencent.com/developer/user/1751610

1.1 概述

  就一个类而言,应该仅有一个引起它变化的原因。应该只有一个职责。如果一个类承担的职责过多,就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当发生变化时,设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生,就要尽可能的遵守单一职责原则。此原则的核心就是解耦和增强内聚性。

1.2 优点

 ① 提高类的可维护性和可读写性:一个类的职责少了,复杂度降低了,代码就少了,可读性也就好了,可维护性自然就高了。  ② 提高系统的可维护性:系统是由类组成的,每个类的可维护性高,相对来讲整个系统的可维护性就高。  ③ 降低变更的风险:一个类的职责越多,变更的可能性就更大,变更带来的风险也就越大,

1.3 案例

  只要写过程序肯定接触过用户管理,用户有众多的信息和行为需要维护,我们将其写到一个接口中,如以下类图所示。虽然都是用户管理,但是用户的属性和行为却没有分开,等于就是大杂烩一锅端了,一个出现为问题可能会影响整个用户管理。这肯定是一个非常恶心的行为,如果我接手这种代码肯定立马辞职回家种地。

202109052054310181.png

  上面这个接口简直是个弟中弟,一般来说我们需要把属性和行为分别抽取为一个单独的接口,UserInfoInter 接口负责用户的属性信息,UserOperInter 接口负责用户操作行为,然后使用 UserInter 接口继承这两个接口。此时产生的 UserImpl 对象就可以在修改该属性是当作 UserInfoInter 使用,操作属性时当作 UserOperInter 使用。

  上面这种方式看似满足要求,但是我们最初将将一个接口拆为两个接口的意义呢?在开发中我们会使用不同的类或接口来完成不同的功能,这里就可以分为 UserInfoInter 接口和 UserInfoImpl 实现类与 UserOperInter 接口和 UserOperImpl 实现类分别来完成属性和行为。以上我们将一个接口拆分为两个接口的行为就要体现了单一职责原则。

  咱们再来强行刚一波,UserInfoInter 接口不是单一职责啊,有 set 也有 get。单一职责原则最难划分的就是职责,一个职责一个接口,但是问题是“职责”是一个没有量化的标准,一个类到底要负责那些职责?这些职责怎么细化?细化后是否都要有一个接口或类?这个都是需要从实际的项目区考虑的。   单一职责使用于接口、类,同时也使用方法,什么意思呢?一个方法尽可能做一件事情,比如一个方法既可以修改用户密码,又可以修改用户名,这个方法的颗粒度很粗。我们尽量让一个方法只做一件事,修改密码交给修改密码的方法,修改用户名的交给修改用户名的方法,不要使用一个修改一个用户信息的方法搞定所有。这样在方法上保证了单一职责原则。   对于接口,我们在设计的时候一定要做到单一,但是对于实现类就需要多方面考虑了,生搬硬套单一职责原则会引起类的剧增,给维护带来非常多的麻烦;而且过分的细分类的职责也为人为的制造系统的负责性,本来一个类可以实现的行为非要拆成两个,然后使用聚合或组合的方式再耦合在一起,这个是人为制造了系统的复杂性,原则是死的,人是活的。

点赞(7)
版权归原创作者所有,任何形式转载请联系作者; Java 技术驿站 >> 七大设计原则之单一职责原则
下一篇
七大设计原则之接口隔离原则