在完成对二十三个经典设计模式的讲解后，我们再来回顾一下一些基本原则，以便在日常开发中更好地理解和应用这些概念。
单一职责原则（SRP，Single Responsibility Principle）定义：一个类或模块应该有且仅有一个改变的原因。在 JavaScript 中，这更多地应用于对象和函数。
最具挑战性的是根据具体场景对单一职责的判断。将一个模块拆分得过于细致并不总是好的，因此我们需要在便利性和稳定性之间找到平衡。
之前讲到的代理模式和装饰器模式都体现了这一原则。
开闭原则（OCP，open-closed principle）定义：软件实体如类、模块和函数应该对扩展开放，对修改关闭。模块应尽量在不修改原有代码的情况下进行扩展。
立即学习“前端免费学习笔记（深入）”；
在日常开发中，我们需要将变化的部分和不变的部分分离出来。在设计结构时，尽可能考虑未来可能变化的部分。
可以通过放置钩子（hook）或使用回调函数的方式来实现扩展。
之前讲到的发布订阅模式、模板方法模式、策略模式和职责链模式都体现了这一原则。
里氏替换原则（LSP，Liskov substitution principle）定义：所有引用基类的地方必须能够透明地使用其子类的对象。简单来说，任何基类可以出现的地方，子类也一定可以出现。
举个例子，如果某个地方可以使用 A 类，B 类继承自 A 类，那么这个地方也一定可以使用 B 类。
这一原则告诉我们在继承类时，如果要实现新功能，不要覆盖父类已实现的方法，而应编写新方法。
在前端开发中，很少编写类和继承，所以这一原则的应用较少。
接口隔离原则（ISP，Interface Segregation Principle）定义：客户端不应依赖它不需要的接口，类间的依赖关系应建立在最小的接口上。简单来说，就是要建立单一的接口，不要建立臃肿庞大的接口。也就是说，接口应尽量细化，同时接口中的方法应尽量少。
举个例子，如果 A 接口有 5 个方法，B 类实现 A 接口，但 B 类只用到其中的 3 个方法，此时可以考虑将 A 接口拆分。
在 JavaScript 中没有接口，因此这一原则不适用。
依赖倒转原则（DIP，Dependency Inversion Principle）定义：程序应依赖于抽象接口，而非具体实现。简单来说，就是要对抽象进行编程，而不是对实现进行编程，这样可以降低客户与实现模块之间的耦合。
这实际上就是常说的面向接口（或基类）编程。
但在 JavaScript 中没有接口和抽象类，因此这一原则的应用较少。
以上五个原则就是经常提到的 SOLID 原则。除了这些，还有其他几个原则。
最小知道原则（LOD，principle of least knowledge）定义：一个软件实体应尽可能少地与其他实体发生相互作用。每个软件单位对其他单位的了解应尽可能少，且仅限于与本单位密切相关的软件单位。
在前端中，实体更多地对应于对象和函数，门面模式可以看作是这一原则的应用。
最小知道原则又称为迪米特法则（LOD，Law of Demeter）。迪米特是宙斯（Zeus）的姐姐，名字的由来可以参考维基百科的解释：
The Greek goddess of Agriculture. The Demeter project was named after Demeter because we were working on a hardware description language Zeus and we were looking for a tool to simplify the implementation of Zeus. We were looking for a tool name related to Zeus and we chose a sister of Zeus: Demeter.
Later we promoted the idea that Demeter-style software development is about growing software as opposed to building software. We introduced the concept of a growth plan which is basically a sequence of more and more complex UML class diagrams.
Growth plans are useful for building systems incrementally.
大意是当时使用了一种名为 Zeus 的硬件语言，然后找到了一种优化 Zeus 的工具。为了建立联系，就选择了 Demeter 这个名字。
此外，引用「JavaScript 设计开发与实现」书中关于两个名字之间的建议：
合成/聚合复用原则（CARP，Composite/Aggregate Reuse Principle）定义：尽量使用合成/聚合，而不是通过继承来实现复用。
KISS 原则定义：Keep It Simple, Stupid，在设计中应注重简约的原则。
YAGNI 原则定义：You aren't gonna need it，表示暂时不需要的就不要做。
DRY 原则定义：Don't Repeat Yourself，不要写重复的代码。
所有这些原则只是帮助我们编写易维护、易扩展的代码，不能为了实现而实现，进行过度设计。
如果某些代码未来完全不需要更改，那就用最简单的方式实现即可。当第二次、第三次修改时再进行重构也不迟。
设计模式和基本原则的应用必须结合具体场景，空谈没有任何意义。
我们只需要先了解这些原则，然后在日常开发中慢慢体会和应用。
