DRY原则

一、DRY原则

• DRY原则：Don’t Repeat Yourselt, 简称DRY。

• 描述：不要重复自己，理解为不要写重复的代码。

• 三种典型的代码重复情况：实现逻辑重复、功能语义重复和代码执行重复。

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

二、什么是代码复用性

• 区分三个概念：代码复用性（Code Reusability）、代码复用（Code Resue)和DRY原则。
• 代码复用表示一种行为：在开发新功能的时候，尽量复用已经存在的代码。
• 代码的可复用性表示一段代码可被复用的特性或能力：我们在编写代码的时候，让代码尽量可复用。
• DRY原则是一条原则：不要写重复的代码。
• 首先，“不重复”并不代表“可复用”。在一个项目代码中，可能不存在任何重复的代码，但也并不表示里面有可复用的代码，不重复和可复用是两个概念。
• 其次，“复用”和“可复用性”关注角度不同。代码“可复用性“是从代码的开发者的角度来讲的，”复用“是从代码的使用者的角度讲的。

三、怎么提高代码复用性

• 减少代码耦合
  • 对于高度耦合的代码，当我们希望复用其中一个功能，想把这个功能的代码抽取出来成为一个独立的模块、类或者函数的时候，往往会发现牵一发而动全身。移动一点代码，就要牵连到很多其他相关的代码。所以，高低耦合的代码会影响到代码的复用性，我们要尽量减少代码耦合。
• 满足单一职责原则
  • 如果职责不够单一，模块、类设计的大而全，那依赖它的代码或者它依赖的代码就会比较多，进而增加了代码的耦合性。越细粒度的代码，代码的通用性会越好，越容易被复用。
• 模块化
  • 这里的模块，不单单指一组类的模块。还可以理解为单个类、函数。善于将功能独立的代码，封装成模块。
• 业务与非业务逻辑分离
  • 越是跟业务无关的代码越是容易复用，越是针对特定业务的代码越难复用。为了复用跟业务无关的代码，我们将业务和非业务逻辑代码分离，抽取成一些通用的框架、类库、组件等。
• 通用代码下沉
  • 从分层的角度来看，越底层的代码越通用、会被越多的模块调用，越应该设计的足够可复用。
• 继承、多态、抽象、封装
  • 利用继承，可以将公共的代码抽取到父类，子类复用父类的方法和属性。
  • 利用多态，可以动态地替换一段代码的逻辑，让这段代码可复用。
  • 越抽象、越不依赖具体的实现，越容易复用。代码封装成模块，隐藏可变的细节、暴露不变的接口，就越容易复用。
• 应用模板等设计模式
  • 一些设计模式，也能提高代码的复用性。比如，模板模式利用了多态来实现，可以灵活地替换其中的部分代码，整个流程模板代码可复用。