设计模式系列-第三章（设计原则-其他原则）

一、迪米特法则（LOD）

       迪米特法则的英文翻译是：Law of Demeter，缩写是 LOD。利用这个原则，能够帮我们实现代码的“高内聚、松耦合”。所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。我们前面讲过的单一职责原则是实现代码高内聚非常有效的设计原则。松耦合是说，在代码中，类与类之间的依赖关系简单清晰。前面讲的依赖注入、接口隔离、基于接口而非实现编程，以及迪米特法则，都是为了实现代码的松耦合。

        “高内聚、松耦合”是一个非常重要的设计思想，能够有效提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围。“高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间依赖关系的设计。“高内聚”有助于“松耦合”，同理，“低内聚”也会导致“紧耦合”。

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

二、KISS原则

       KISS（Keep It Simple and Stupid） 原则是保持代码可读和可维护的重要手段。KISS 原则中的“简单”并不是以代码行数来考量的。代码行数越少并不代表代码越简单，我们还要考虑逻辑复杂度、实现难度、代码的可读性等。而且，本身就复杂的问题，用复杂的方法解决，并不违背 KISS 原则。除此之外，同样的代码，在某个业务场景下满足 KISS 原则，换一个应用场景可能就不满足了。

对于如何写出满足 KISS 原则的代码，总结了下面几条指导原则：

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

三、YAGNI原则

        YAGNI 原则的英文全称是：You Ain’t Gonna Need It。当用在软件开发中的时候，它的意思是：不要去设计当前用不到的功能；不要去编写当前用不到的代码。实际上，这条原则的核心思想就是：不要做过度设计。

       YAGNI 原则跟 KISS 原则并非一回事儿。KISS 原则讲的是“如何做”的问题（尽量保持简单），而 YAGNI 原则说的是“要不要做”的问题（当前不需要的就不要做）。

四、DRY原则

         Don’t Repeat Yourself。中文直译为：不要重复自己。将它应用在编程中，可以理解为：不要写重复的代码。实际上，重复的代码不一定违反 DRY 原则，而且有些看似不重复的代码也有可能违反 DRY 原则。实现逻辑重复，但功能语义不重复的代码，并不违反 DRY 原则（比如校验人名和校验密码合法，目前可能能校验方面一样，未来可能不一样，因为本来校验的业务不同）。实现逻辑不重复，但功能语义重复的代码，也算是违反 DRY 原则。除此之外，代码执行重复也算是违反 DRY 原则。

DRY原则重要的是提升代码的复用性。在设计每个模块、类、函数的时候，要像设计一个外部 API 一样去思考它的复用性：

• 减少代码耦合
• 满足单一职责原则
• 模块化业务与非业务逻辑分离
• 通用代码下沉
• 应用模板等设计模式