设计原则
SOLID原则
SOLID 是面向对象设计(OOD)的五大基本原则的首字母缩写组合,由俗称“鲍勃大叔”的Robert C.Martin在《敏捷软件开发:原则、模式与实践》一书中提出来。这些原则结合在一起能够指导程序员开发出易于维护和扩展的软件。这五大原则分别是:S—单一职责原则,O—开放封闭原则,L—里氏替换原则,I—接口隔离原则,D—依赖倒置原则
单一职责原则
核心思想
一个类应该有且仅有一个原因引起它的变更
一个类只负责一项功能或一类相似的功能。当然这个“一”并不是绝对的,应该理解为一个类只负责尽可能独立的一项功能,尽可能少的职责。就好比一个人的精力、时间都是有限的,如果什么事情都做,那么什么事情都做不好;所以应该集中精力做一件事,才能把事情做好
优缺点:
优点:
- 功能单一,职责清晰
- 增强可读性,方便维护
缺点: - 拆分得太详细,类的数量会急剧增加
- 职责得度量没有统一的标准,需要根据项目实现情况而定
开放封闭原则
核心思想
软件实体(如类、模块、函数等)应该对拓展开放,对修改封闭
在一个软件产品的生命周期内,不可避免会有一些业务和需求的变化,我们在设计代码的时候应该尽可能地考虑这些变化。在增加一个功能时,应当尽可能地不去改动已有的代码;当修改一个模块时不应该影响到其他模块。
里氏替换原则
核心思想
所有能引用基类的地方必须能透明地使用其子类的对象。
只要父类能出现的地方子类就能出现(就可以用子类来替换它)。反之,子类能出现的地方父类不一定能出现(子类拥有父类的所有属性和行为,但子类拓展了更多的功能)。
依赖倒置原则
核心思想
高层模块不应该依赖低层模块,二者都该依赖其抽象。抽象不应该依赖细节,细节应该依赖抽象
高层模块就是调用端,低层模块就是具体实现类。抽象就是指接口或抽象类,细节是指具体的实现类。也就是说,我们只依赖抽象编程。
把具有相同特征或相似功能的类,抽象成接口或抽象类,让具体的实现类继承这个抽象类(或实现对应的接口)。抽象类(接口)负责定义统一的方法,实现类负责具体功能的实现。
接口隔离原则
核心思想
客户端不应该依赖它不需要的接口。用多个细粒度的接口来替代由多个方法组成的复杂接口,每一个接口服务于一个子模块。
建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为不同类别的类建立专用的接口,而不要试图建立一个很庞大的接口供所有依赖它的类调用。
接口尽量小,但是要有限度。当发现一个接口过于臃肿时,就要对这个接口进行适当的拆分。但是如果接口过小,则会造成接口数量过多,使设计复杂化。所以接口大小一定要适度。
优点
- 提高程序设计的灵活性
- 提高内聚,减少对外交互
- 为依赖接口的类定制服务
是否一定要遵守这些设计原则
软件的设计是一个循序渐进、逐步优化的过程
- 单一职责原则告诉我们实现类要职责单一
- 里氏替换原则告诉我们不要破坏继承体系
- 依赖倒置原则告诉我们要面向接口编程
- 接口隔离原则告诉我们在设计接口的时候要精简单一
- 开放封闭原则告诉我们要对扩展开放,对修改封闭
LoD原则
一个类对自己依赖的类知道的越少越好,这个类只需要和直接的对象进行交互,而不用在乎这个对象的内部组成结构。
KISS原则(Keep It Simple and Stupid)
“简单”就是要让你的程序能简单、快速地被实现;“愚蠢”是说你的设计要简单到傻瓜都能理解,即简单就是美!
为什么要简单呢?因为大多数技术团队,成员的技术水平都参差不齐。如果你的程序设计得太复杂,有些成员可能无法理解这种设计的真实意图,而且复杂的程序讲解起来也会增加沟通成本。为什么说愚蠢呢?对有同样需求的一个软件,每个人都有自己独特的思维逻辑和实现方式,因此你写的程序对于另一个人来说就是个陌生的项目。所以你的代码要愚蠢到不管是什么时候,不管是谁来接手这个项目,都能很容易地被看懂;否则,不要让他看到你的联系方式和地址,你懂的。
DRY原则(Don’t Repeat Yourself)
不要重复你的代码,即多次遇到同样的问题,应该抽象出一个共同的解决方法,不要重复开发同样的功能。也就是要尽可能地提高代码的复用率。
要遵循DRY原则,实现的方式很多:
- 函数级别的封装:把一些经常使用的、重复出现的功能封装成一个通用的函数。
- 类级别的抽象:把具有相似功能或行为的类进行抽象,抽象出一个基类,并把这几个类都有的方法提到基类去实现
- 泛型设计
YAGNI原则(You Aren’t Gonna Need It)
你没必要那么着急,不要给你的类实现过多的功能,直到你需要它的时候再去实现。
这个原则简而言之为—只考虑和设计必需的功能,避免过度设计。只实现目前需要的功能,在以后需要更多功能时,可以再进行添加。如无必要,勿增加复杂性。
软件开发首先是一场沟通博弈。它背后的指导思想就是尽可能快、尽可能简单地让软件运行起来(do the simplest thing that could possiblywork)。
Rule Of Three原则
Rule of three 称为“三次法则”,指的是当某个功能第三次出现时,再进行抽象化,即事不过三,三则重构。
这个准则表达的意思是:第一次实现一个功能时,就尽管大胆去做;第二次做类似的功能设计时会产生反感,但是还得去做;第三次还要实现类似的功能做同样的事情时,就应该去审视是否有必要做这些重复劳动了,这个时候就应该重构你的代码了,即把重复或相似功能的代码进行抽象,封装成一个通用的模块或接口。
理由:
- 省事
- 容易发现模式
- 防止过度冗余
CQS原则(Command-Query Separation)
- 查询(Query):当一个方法返回一个值来回应一个问题的时候,它就具有查询的性质;
- 命令(Command):当一个方法要改变对象的状态的时候,它就具有命令的性质。