设计模式-KISS,YAGNI,DRY,LOD 原则(十三)

纲要

KISS,YAGNI,DRY,LOD 原则

KISS原则

Keep It Simple and Stupid

尽量保持简单

  1. 代码行数越少就越“简单”吗？

    答案是否定的，实现逻辑需要简单，易维护，不过度优化

  2. 代码逻辑复杂就违背 Kiss 原则吗？

    ​ 答案也是否定的，需要考虑逻辑复杂度，实现难度，可代码的可读性。

总结

  1. 不要使用很另类的技术实现代码
  2. 不要重复造轮子，善于使用已有的工具类库
  3. 不要过度优化

一句话：KISS原则讲”如何做“的问题（尽量保持简单）

tip: 在开发中不要过度设计，越是能用简单的方法解决复杂的问题，越能体现一个人的能力。

YAGNI原则

You Ain’t Gonna Need It

你不会需要它

核心思想：不要做过度设计。

一句话：YAGNI原则讲”要不要做“的问题（当前不需要的就不要做）

DRY原则

Don’t Repeat Yourself

不要重复自己，即不要写重复的代码。

三种典型的代码重复情况：

  1. 实现逻辑重复
    • 实现逻辑重复，但功能语义不重复的代码，并不违反DRY原则。
  2. 功能语义重复
    • 实现逻辑不重复，但功能语义重复的代码，也算是违反DRY原则。
  3. 代码执行重复
    • 重复执行相同的代码也是违反DRY原则。

代码复用性

三个不同的概念：

  1. 代码复用性(Code Reusability)
    • 表示一段代码可被复用的特性或能力
  2. 代码复用(Code Resue)
    • 尽量复用已经存在的代码
  3. DRY原则(Don’t Repeat Yourself)
    • 不要写重复的代码

复用和可复用性关注角度不同

“可复用性”是从代码开发者的角度出发的。

“复用”是从代码使用者的角度出发的。

实际上目的是一样的，都是为了减少代码量，提高代码可读性，可维护性。

提高复用性方法

  1. 减少代码耦合
    • 高度耦合的代码，往往是牵一发而动全身。
    • 尽量减少代码耦合，提高代码的复用性。
  2. 满足单一职责原则
    • 模块，类，函数尽量职责单一。
    • 越细粒度的代码，代码的通用性会越好，越容易被复用。
  3. 模块化
    • 类， 函数要尽量将独立的功能封装成模块。
    • 独立的模块像一块一块积木，更加容易复用，可以直接拿来搭建更加复杂的系统。
  4. 业务与非业务逻辑分离
    • 越是跟业务无关的代码越是容易复用。
    • 越是针对特定业务的代码越难复用。
    • 为了复用跟业务无关的代码，将业务与非业务逻辑代码分离，抽取成一些通用的框架，类库，组件等
  5. 通用代码下沉
    • 从分层的角度来看，越底层的代码越通用，会被越多模块调用，越应该设计得足够可复用。
    • 避免交叉调用导致关系混乱
      • 只允许上层代码调用下层代码及同层代码之间调用。
      • 杜绝下层代码调用上层代码。
    • 通用的代码尽量下沉到更下层。
  6. 继承，多态，抽象，封装
    • 利用继承：可以将公共的代码抽取到父类，子类复用父类的属性和方法。
    • 利用多态：动态地替换一段代码的部分逻辑，让这段代码可复用。
    • 利用抽象：越抽象，越不依赖具体实现，越容易复用。
    • 利用封装：代码封装模块，隐藏可变的细节，暴露不变的接口，就越容易复用。
  7. 应用模板等设计模式
    • 使用设计模式，提高代码复用性。
  8. 其它
    • 泛型编程，也是提高代码复用性。
    • 复用意识非常重要，时常要多去思考一下，这部分代码是否可以抽取出来，作为一个独立的模块，类或函数供多处使用。
    • 设计每个模块，类，函数的时候，要像设计一个外部API一样，去思考它的复用性。

LOD原则

Low of Demeter

最少知道原则。

每个模块只应该了解那些与它关系密切的模块的有限知识，或者说，每个模块只和自己的朋友“说话”，不和陌生人“说话”。

从类的角度描述：不该有直接依赖关系的类之间，不要有依赖; 有依赖关系的类之间，尽量只依赖必要的接口（也就是定义中“有限知识）。

何为“高内聚，松耦合”

image-20210209203036244

**一句话：**高内聚用来指导类本身的设计，松耦合用来指导类与类之间依赖关系的设计。

  1. “高内聚，松耦合是一个非常重要的设计思想，能够有效地提高代码可读性和可维护性，缩小功能改动导致的代码改动范围。
  2. “高内聚，松耦合”是一个比较通用的设计思想，可以用来指导不同粒度代码的设计与开发，如系统，模块，类和函数。也可以应用不同开发场景，如微服务，框架，组件，类库等。

tip: 如单一职责原则，基于接口而非实现编程都是实现“高内聚，松耦合”的目的。

如何理解“高内聚”，松耦合“

  1. “高内聚，松耦合”是一个非常重要的设计思想，能够有效提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。
  2. 高内聚：用来指导类本身的设计。
  3. 松耦合：用来指导类与类之间依赖关系的设计。
  4. 所谓高内聚：就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一类中。相近的功能往往被同时修改，放到同一个类中，修改会比较集中。
  5. 所谓松耦合：就是指在代码中，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动也不会或者很少导致依赖类的代码改动。

如何理解“迪米特法则”

  1. 不该有直接依赖关系的类之间，不要有依赖。
  2. 有依赖关系的类之间，尽量只依赖必要的接口。
  3. 迪米特法则只希望减少类之间的耦合，让类越独立越好。
  4. 每个类都应该少了解系统其它部分。
  5. 一旦发生变化，需要了解这一变化的类就会比较少。

不同原则角度出发不同，最终都是写出扩展性，可维护性，可阅读性的好代码。

  1. 高内聚，松耦合
    • 基于设计思想考量
  2. 单一职责原则
    • 基于自身提供的功能考量
  3. 接口隔离原则
    • 基于外部关系上只依赖需要的抽象考量
  4. 基于接口而非实现编程
    • 基于使用者考量
  5. 迪米特法则
    • 基于关系考量

空树之空