SOLID原则在上个世纪80年代被发明出来。
源于Uncle Bob在设计USENET程序是对一些软件开发原则的争吵。
经过了一些修改,Uncle Bob在2000年早些时候进行了阐述。
直到2004年这些原则被整理成为SOLID原则,这是5个独立设计原则名字的首字母缩写。
- S represents the Single Responsibility principle(单一职责原则)
- O represents the Open Closed principle (开放封闭原则)
- L represents the Liskov Substitution principle (里氏替换原则)
- I represents the Interface Segregation principle (接口隔离原则)
- D represents the Dependency Inversion principle (依赖倒置原则)
当进行独立的模块开发或者大型架构设计时,SOLID原则非常实用。
单一职责(SRP)
单一职责试图提高一个类、模块、或者函数的凝聚力。凝聚力是对模块内部功能的之间的一个描述。
SRP可能是最容易让人误解的一个原则,单看名字很容易理解为一个模块只应该做一件事情,但是SOLID里的SRP却不是这个含义。
为了让大家理解这个原则背后正在的含义,有这样一句用于补充的描述:
一个软件模块有一个,且仅有一个让它改变的理由。
当这句话似乎并没有说明白这个理由到底是啥?
为了解决这个疑问,Uncle Bob在2014年写了一篇文章单独说明了这个理由到底是啥。
以人为本
我们开发一个应用,实际上是实现某些人的诉求,应用是否改变,本质上都来源于人的意志。
一个模块应该允许哪一些来指导变更,就变的很重要。
这个原则实际上是想表达,一个类,模块或者函数只应该允许一个人请求变更。
当得知这个原则的本质后,我回想起了很多线上事故,都能追述到不同的需求方在要求修改同一个页面的内容。
刚好这个页面并没有做好隔离,没有把每个需求方的代码隔离在不同的区域,导致这些变更非常容易出现错误,且变更起来异常困难。
可现实就是存在多个部门想在一个用户经常访问的页面添加功能。
产品想加一些数据展示模块。
增长想加引导分享弹窗。
运营想上一个活动广告位。
这些功能可能都会做成单独的组件,但是它们会同时由页面组件进行调度。
在每一次有人来为这个页面添加功能时,都不可避免要修改页面组件,这就导致了页面组件被更新的理由变得多样。
除非我们固定页面的调度机制,在添加或者修改页面功能时做到并不需要修改页面组件本身。
而且把每个部门对应修改的逻辑单独聚合起来,才能做到SRP原则里描述的那样。
确保每个类、模块、函数都只对一个特殊的需求方负责,是一个写好代码的重要原则。
也是最难的一个原则,因为这不是写代码的人能完全控制的,多方想改同一个逻辑的情况不是极少数,这就要求我们能对需求进行上游控制,至少确保某个逻辑的上游只有一个对接人。
参考文章:
Clean Coder Bloghttps://blog.cleancoder.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html