在完成对二十三个经典设计模式的讲解后，我们再来回顾一下一些基本原则，以便在日常开发中更好地理解和应用这些概念。
单一职责原则（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 原则。除了这些，还有其他几个原则。
闪灵CMS企业建站系统是淄博闪灵网络科技有限公司开发的一款专门为企业建站提供解决方案的产品，前端模板样式主打HTML5模板，以动画效果好、页面流畅、响应式布局为特色，程序主体采用PHP+MYSQL构架，拥有独立自主开发的一整套函数、标签系统，具有极强的可扩展性，设计师可以非常简单的开发出漂亮实用的模板。系统自2015年发布第一个版本以来，至今已积累上万用户群，为上万企业提供最优质的建站方案。
最小知道原则（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，不要写重复的代码。
所有这些原则只是帮助我们编写易维护、易扩展的代码，不能为了实现而实现，进行过度设计。
如果某些代码未来完全不需要更改，那就用最简单的方式实现即可。当第二次、第三次修改时再进行重构也不迟。
设计模式和基本原则的应用必须结合具体场景，空谈没有任何意义。
我们只需要先了解这些原则，然后在日常开发中慢慢体会和应用。
