设计原则--DRY原则

DRY原则，英文名Don't Repeat Yourself 。中文直译：“不要重复自己”。很多人可能会对这条原则会有误解，认为长得一样的两段代码违反了DRY原则。其实不然，重复的代码不一定违反DRY原则，而不重复的代码也可能违反DRY原则。

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

1、实现逻辑重复，但语义不重复，并不违反DRY原则。

2、实现逻辑不重复，但语义重复，也算是违反了DRY原则

3、如果代码重复执行，那我们也认为它违反了DRY原则

注：实现逻辑重复指得是代码重复，语义不重复指得是两个函数干的是完全不同的两件事情。

这里有三个概念需要区分：代码复用性(code Reusability) 、代码复用(code Reuse)、DRY原则。

代码复用表示一种行为，我们在开发新功能的时候，尽量复用已经重复的代码。

代码复用性表示一段代码复用的特性和能力。

DRY原则上面已经介绍了。不要重复自己

“复用”和“可复用性”关注的角度不同，代码“可复用性”是从开发者的角度来讲的，“复用”是从使用者的角度来讲的。比如：A同时编写了一个urlUtils类，代码的“可复用性”好，B同时在开发的时候，直接“复用”A同事开发的urlUtils类。

尽管复用、可复用性、DRY原则这三者有所区别，但实际上目的都是类似的，都是为了减少代码量，提高代码的可读性和可维护性。除此之外，复用已经测试过的老代码，bug会比从0开始要少。

1）、减少代码的耦合

对于高度耦合的代码，当我们希望复用其中一个功能的时候，想要把这个功能的代码抽取出来成为一个独立的模块、类或者函数的时候，往往会牵一发而动全身。移动一点代码会牵连很多其他的代码。所以高度耦合的代码会影响可复用性，我们要尽量减少代码的耦合

2）、满足单一职责原则

如果职责不够单一，模块、类设计的大而全，那依赖它的代码或者依赖它的类就会比较多，进而增加了代码的耦合。根据上一点也会影响代码的复用性，相反，越细粒度的代码，通用性越好，越容易被复用

3）、模块化

这里的“模块”，不单单指一组类构成的模块，还可以理解为单个类、函数。我们要善于将功能独立的代码，封装成模块。独立的模块就像一块一块的积木，更加容易复用，可以直接用来搭建更加复杂的系统。

4）、业务与非业务代码分离

越是跟业务无关的代码越容易复用，越是针对特定业务的代码越难复用。所以，为了复用跟业务无关的代码，我们将业务和非业务逻辑代码分离，抽取成一些通用的框架，类库、组件等。

5）、通用代码下沉

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

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

继承，将公共的代码抽取到父类中，子类复用父类的属性和方法。多态，可以动态的替换一段代码的部分逻辑，让这段代码可复用。除此之外，抽象和封装，从更广义的层面，而非狭义的面向对象特性的层面来理解的话，越抽象，越不依赖具体实现，越容易复用。代码封装成模块，隐藏可变的细节，暴露不变的接口，越容易复用。

7）、使用模板等设计模式

一些设计模式，也能提高代码的复用性。

实际上，除了上面讲的方法之外，复用的意识也是也很重要。在设计每个模块、类、函数的时候，要像设计一个外部API一样思考它的复用性。

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

参考：设计模式之美--王争