楼子湾

导航

统计
 

单一职责原则(Single Resposibility Principle)

定义:一个类应该有且仅有一个变化的原因

这里的变化是指修改代码,如修复bug,功能不满足修改等等,也就是说你修改了一个方法的代码,不能导致其他方法的代码也需要修改

具体做法:将不同的职责封装到不同的独立类中

为什么要封装到不同的独立类中?是由于每个职责都是一个变化点。当需求发生变化时,这个变化通过更改职责相关的类来体现

 例如:数据库将连接数据库和执行sql分开到两个类中,一个只负责和数据库连接,一个只负责操作sql

实际应用:

如WEB应用分了controller service  dao

dao--只针对书库

service-只负责业务

controller--负责和外界交互

大家发现,我们有很多controller 很多service很多dao,是的我们每个表是不是要对应一个dao,一个service

1.根据职责不同结构上的划分

2.一张表一个DAO

3.同一个service中的方法不互调,因为每个细分又是不同职责,一个代码的变更可能引起其他的功能无法使用或者修改

有人估计要说,那DAO层的crud为什么不单独隔离到独立的类中,crud操作数据的这几个接口基本上不会变化,变化的也就是表,表变化,mapper文件的sql要修改,对应的实体类要修改

 

有点:

1.提高类的可读性和可维护性

一个类的职责少了,复杂度就降低了,代码 就少了,可读性就提高了,可维护性就自然提高了

2.提高系统的可维护性

一个系统是由各个类组成的,如果每个类的可维护性高了,系统的可维护性自然也高了

3.降低了变更的风险

一个类的职责越多,变更的可能性就越大,变更带来的风险就越高

合理的职责分解:

相同的职责放在一起,不同的职责分解到不同的接口和实现中去,这个是最容易也是最难运用的原则,职责有时候不好划分或者不经意间就违反了单一职责原则,

关键是要从业务出发,从需求出发,识别出同一种类型的职责

posted on 2020-03-08 16:01  楼子湾  阅读(...)  评论(...编辑  收藏