设计模式那些事(1)——写出好代码，从了解设计原则开始

一、单一职责原则

概念

一个类只负责完成一个职责或者功能。
不要设计大而全的类，要设计粒度小、功能单一的类。

意义

单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性。

示例

出现下面这些情况就有可能说明这类的设计不满足单一职责原则:

• 类中的代码行数、函数或者属性过多，会影响代码的可读性和可维护性;
• 类依赖的其他类过多，或者依赖类的其他类过多，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分;
• 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性;
• 比较难给类起一个合适的名字，这就说明类的职责定义得可能不够清晰;
• 类中大量的方法都是集中操作类中的某几个属性，那就可以考虑将这几个属性和对应的方法拆分出来。

二、开闭原则

概念

添加一个新的功能，应该是通过在已有代码基础上扩展代码(新增模块、类、方法、属性等)，而非修改已有代码(修改模块、类、方法、属性等)的方式来完成。

开闭原则并不是说完全杜绝修改，而是以最小的修改代码的代价来完成新功能的开发。

意义

修改代码可能会带来问题，尽量将修改代码量做到最小、可控，那么出现问题几率就越小。扩展性是代码质量最重要的衡量标准之一。在 23 种经典设计模式中，大部分设计模式都是为了解决代码的扩展性问题而存在的，主要遵从的设计原则就是开闭原则。

如何做到

1、我们要时刻具备扩展意识、抽象意识、封装意识。
在写代码的时候，我们要多花点时间思考一下，这段代码未来可能有哪些需求变更，如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，在不改动代码整体结构、做到最小代码改动的情况下，将新的代码灵活地插入到扩展点上。

2、要想识别出尽可能多的扩展点，就要对业务有足够的了解，能够知道当下以及未来可能要支持的业务需求。

3、最常用来提高代码扩展性的方法有:多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式(比如，装饰、策略、模板、职责链、状态)。

三、里式替换原则

概念

子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏。

父类定义了函数的“约定”(或者叫协议)，那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。

示例

违反里式替换原则的例子：

1. 子类违背父类声明要实现的功能

父类中提供的 sortOrdersByAmount() 订单排序函数，是按照金额从小到大来给订单排序 的，而子类重写这个 sortOrdersByAmount() 订单排序函数之后，是按照创建日期来给订单排序的。

2. 子类违背父类对输入、输出、异常的约定

在父类中，某个函数约定:运行出错的时候返回 null;获取数据为空的时候返回空集合 (empty collection)。而子类重载函数之后，实现变了，运行出错返回异常 (exception)，获取不到数据返回 null。

3. 子类违背父类注释中所罗列的任何特殊说明

父类中定义的 withdraw() 提现函数的注释是这么写的:“用户的提现金额不得超过账户余额......”，而子类重写 withdraw() 函数之后，针对 VIP 账号实现了透支提现的功能，也就是提现金额可以大于账户余额

四、依赖倒置原则

概念

高层模块不要依赖低层模块，高层模块和低层模块应该通过抽象来互相依赖。除此之外，抽象不要依赖具体实现细节，具体实现细节依赖抽象。

所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属低层。

依赖注入(DI)

不通过 new() 的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递 (或注入)给类使用。

通过依赖注入的方式来将依赖的类对象传递进来，这样就提高了代码的扩展性，我们可以灵活地替换依赖的类。

示例

Notification 类负责消息推送，依赖 MessageSender 类实现推送商品促销、验证码等消息给用户。

public class Notification {
  private MessageSender messageSender;

// 通过构造函数将 messageSender 传递进来
public Notification(MessageSender messageSender) {
    this.messageSender = messageSender;
  }

public void sendMessage(String cellphone, String message) {
    //... 省略校验逻辑等...
    this.messageSender.send(cellphone, message);
    } 
}

// 使用 Notification
MessageSender messageSender = new MessageSender(); 
Notification notification = new Notification(messageSender);

五、KISS原则

概念

尽量保持简单。
这意味着很容易读懂，bug 比较难隐藏。

如何做

• 不要使用同事可能不懂的技术来实现代码。比如前面例子中的正则表达式，还有一些编程语言中过于高级的语法等。
• 不要重复造轮子，要善于使用已经有的工具类库。经验证明，自己去实现这些类库，出 bug 的概率会更高，维护的成本也比较高。
• 不要过度优化。不要过度使用一些奇技淫巧(比如，位运算代替算术运算、复杂的条件语句代替 if-else、使用一些过于底层的函数等)来优化代码，牺牲代码的可读性。

六、YAGNI原则

概念

不要做过度设计，即不要去设计当前用不到的功能;
不要去编写当前用不到的代码。

KISS 原则讲的 是“如何做”的问题(尽量保持简单)，而 YAGNI 原则说的是“要不要做”的问题(当前不需要的就不要做)。

七、DRY 原则

概念

不要写重复的代码。

如何提高代码复用性

1、减少代码耦合

对于高度耦合的代码，当我们希望复用其中的一个功能，想把这个功能的代码抽取出来成为一个独立的模块、类或者函数的时候，往往会发现牵一发而动全身。

2、满足单一职责原则

越细粒度的代码，代码的通用性会越好，越容易被复用。

3、模块化

我们要善于将功能独立的代码，封装成模块。独立的模块就像一块一块的积木，更加容易复用，可以直接拿来搭建更加复杂的系统。

4、业务与非业务逻辑分离

越是跟业务无关的代码越是容易复用，越是针对特定业务的代码越难复用。

5、通用代码下沉

从分层的角度来看，越底层的代码越通用、会被越多的模块调用，越应该设计得足够可复用。一般情况下，在代码分层之后，为了避免交叉调用导致调用关系混乱，我们只允许上层代码调用下层代码及同层代码之间的调用，杜绝下层代码调用上层代码。所以，通用的代码我们尽量下沉到更下层。

6、继承、多态、抽象、封装

利用继承，可以将公共的代码抽取到父类，子类复用父类的属性和方法。利用多态，我们可以动态地替换一段代码的部分逻辑，让这段代码可复用。
越抽象、越不依赖具体的实现，越容易复用。
代码封装成模块，隐藏可变的细节、暴露不变的接口，就越容易复用。

7、应用模板等设计模式

一些设计模式，也能提高代码的复用性。比如，模板模式利用了多态来实现，可以灵活地替换其中的部分代码，整个流程模板代码可复用。

8、“Rule of Three”原则

我们在第一次写代码的时候，如果当下没有复用的需求，而未来的复用需求也不是特别明确，并且开发可复用代码的成本比较高，那我们就不需要考虑代码的复用性。在之后我们开发新的功能的时候，发现可以复用之前写的这段代码，那我们就重构这段代码，让其变得更加可复用。

八、迪米特法则（最小知识原则）

概念

不该有直接依赖关系的类之间，不要有依赖;
有依赖关系的类之间，尽量只依赖必要的接口(也就是定义中的“有限知识”)。
迪米特法则是希望减少类之间的耦合，让类越独立越好。每个类都应该少了解系统的其他部分。一旦发生变化，需要了解这一变化的类就会比较少。

迪米特法则如何实现“高内聚、松耦合”

“高内聚、松耦合”是一个非常重要的设计思想，能够有效地提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。

所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。

松耦合是说，在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。

参考资料：《设计模式之美》