代码抽象三个原则

代码抽象三原则是指在进行软件开发时，为了实现代码的高重用性和减少工作量，从具体问题中提取出具有共性的模式，并使用通用的解决方法来处理这些模式的三个原则。一般来说，这三个原则包括：

1. 高内聚：一个模块应尽可能独立地完成其功能，与其他模块的关联度要尽可能低。这样可以提高模块的可靠性，减少模块间的耦合度。

2. 低耦合：一个模块与其他模块之间的依赖关系应该尽可能地减少，尽量减少模块间的信息传递和交互。这样可以提高系统的可维护性和可扩展性。

3. 高扇入：一个模块应该尽可能地被其他模块调用，这样可以提高代码的重用性，减少重复代码的数量。

这些原则可以帮助开发人员更好地设计软件架构，提高代码的可维护性和可重用性，降低开发成本和风险。

DRY 原则

DRY 我们都非常熟悉了，Don't Repeat Yourself 的缩写。意思就是不要重复写代码。

 If you need it once, build it. If you need it twice, abstract it.

这个原则可能是所有工程师最早接触到的关于抽象的一个技巧。当你的代码重复的时候，那么你就需要考虑抽象成公共的组件、公共的方法、函数等。为的就是不让自己对同一个功能的实现写多遍代码。

YAGNI 原则

YAGNI 是 You aren't gonna need it 的缩写。意思是“你将不需要它”。

YAGNI 是极限编程的一个原则，说的是除非真的有必要，要不然不要添加额外的功能。因为你以为的功能其实你并不需要它。

极限编程的原则提倡尽可能快、尽可能简单的让代码运行起来（do the simplest things that could possibly work, DTSTTCPW）。不要把太多的精力放在抽象上，这样会浪费很多时间，无法实现让软件快速运行起来的目标。

但实际上 YAGNI 和 DRY 这二者存在矛盾。DRY 提倡的是抽象，提取通用的功能、模块。而 YAGNI 则提倡快速运行软件，不要添加额外的功能，不要进行过多的抽象。

所以在这两个规则下，还需要

Rules of Three

Rules of Three 叫做三次法则。来自于《重构-改善既有代码设计》的重构原则。

当第一次做某件事时只管去做；第二次做类似的事情会产生反感，但无论如何还是可以去做；第三次再做类似的事情，你就应该重构。

这个原则很好的解决了 DRY 和 YAGNI 的冲突。当一个功能重复3次及以上时，才着手进行抽象。

之所以加入 Rules of Three 原则，是有下面几个好处：

1. 方便省事。如果一个功能只有在一两个地方用到，那么就没有必要进行抽 象。不仅对于开发者来说省事，对于后面接手的人来说，理解代码也更加方便。毕竟经过抽象后的代码理解起来肯定不如抽象前直观

2. 容易发现共性。多一个东西重复多次后，要发现其共性的地方就更容易了

3. 防止过度冗余。同一个功能写多次代码，管理起来非常麻烦。当需要变更时，需要更改多次，非常不方便。所以实际工作中，代码重复最多允许出现一次，再多就需要抽象了。

所以一开始那句话就应该改成：

If you need something once, build it. If you need something twice, pay attention. If you need it a third time, abstract it.

最后

好的代码并不是一味的抽象，好的代码应该是在可读性、开发成本以及代码冗余之间寻找一个平衡点。

所以我们在对代码进行抽象前，可以参考下代码的抽象三原则。

参考文章：https://lostechies.com/derickbailey/2012/10/31/abstraction-the-rule-of-three/