设计原则

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）：当一个方法要改变对象的状态的时候，它就具有命令的性质。