设计模式核心原则
1. SOLID 五大原则
1.1 单一职责原则 (Single Responsibility Principle)
- 核心思想：一个类或一个函数应该只做一件事。如果一个对象承担的职责过多，就等于把这些职责耦合在了一起。
- JS 实战：不要写一个既负责获取数据、又负责格式化数据、还负责渲染 DOM 的大函数。应该将其拆分为三个独立的小函数。
1.2 开闭原则 (Open-Closed Principle)
- 核心思想：对扩展开放，对修改关闭。
- 解释：当需求变化时，你应该通过增加新代码来扩展功能，而不是去修改已经写好的、经过测试的旧代码。
- JS 实战：这是策略模式和装饰器模式的灵魂。利用配置文件或插件机制来增加功能，而不是在大函数的
if-else里硬写。
1.3 里氏替换原则 (Liskov Substitution Principle)
- 核心思想：子类必须能够完全替换掉它们的父类，而不会导致程序出错。
- 解释：子类不应该覆盖父类中已经实现的非抽象方法，否则会破坏继承的意义。
- JS 实战：如果你写了一个
Bird类有fly方法，那么Ostrich（鸵鸟）类就不应该继承Bird，或者你应该把fly拆分出来。
1.4 接口隔离原则 (Interface Segregation Principle)
- 核心思想：不应该强迫客户依赖于它们不使用的接口。
- 解释：一个接口（在 JS 中通常指对象的方法集合）不应该过于臃肿。
- JS 实战：如果一个组件只需要“读取”权限，就不要传给它一个包含“读取、写入、删除”所有方法的巨大权限对象。
1.5 依赖倒置原则 (Dependency Inversion Principle)
- 核心思想：面向接口编程，而不是面向实现编程。
- 解释：高层模块不应该依赖于低层模块，两者都应该依赖于抽象。
- JS 实战：你的业务组件不应该直接依赖具体的
Axios实例，而应该依赖一个通用的request接口。这样当你把底层从Axios换成Fetch时，业务逻辑不需要改动。
2. 补充重要原则
2.1 DRY 原则 (Don't Repeat Yourself)
- 核心思想：不要写重复的代码。
- 做法：通过抽象和封装，将共有的逻辑提取出来。如果同一段代码你写了三次，就该考虑重构它了。
2.2 KISS 原则 (Keep It Simple, Stupid)
- 核心思想：保持简单，不要炫技。
- 做法：能用简单的代码解决问题，就不要强行套用复杂的设计模式。简单意味着好维护、易调试。
2.3 最少知识原则 (Law of Demeter / Least Knowledge)
- 核心思想：一个对象应该对其他对象有尽可能少的了解。
- JS 实战：这是中介者模式的核心。对象 A 想改对象 C，不应该通过
A -> B -> C这种长链条，而应该通过一个中介者来管理。
原则与模式的关系总结
| 设计原则 | 对应的典型设计模式 |
|---|---|
| 单一职责 (S) | 代理模式、单例模式、装饰器模式 |
| 开闭原则 (O) | 策略模式、观察者模式、适配器模式 |
| 依赖倒置 (D) | 工厂模式、模板方法模式 |
| 最少知识 | 中介者模式、外观模式 |