vault backup: 2026-11-07 16:33:44

0 编程/设计模式究竟有几个原则.md

@@ -0,0 +1,18 @@
+最早总结的设计模式只有 5 个, 即`SOLID`:
+
+- `单一职责原则 (Single Responsibility Principle, SRP)`：一个类应该只有一个引起变化的原因，即一个类应该只有一个责任。
+- `开闭原则 (Open/Closed Principle, OCP)`：软件实体（类、模块、函数等）应该对扩展开放，对修改关闭，即应该通过扩展来实现变化，而不是通过修改已有的代码。
+- `里氏替换原则 (Liskov Substitution Principle, LSP)`：子类型必须能够替换其基类型，即派生类必须能够替换其基类而不影响程序的正确性。
+- `接口隔离原则 (Interface Segregation Principle, ISP)`：不应该强迫客户端依赖于它们不使用的接口。应该将大接口拆分成更小的、更具体的接口，以便客户端只需知道它们需要使用的方法。
+- `依赖倒置原则 (Dependency Inversion Principle, DIP)`：高层模块不应该依赖于低层模块，二者都应该依赖于抽象。抽象不应该依赖于具体实现细节，具体实现细节应该依赖于抽象。
+
+后来增加了两个规则, 这些后加的规则相较来说更具体, 更有指导性. 我们从原则解释中可以看到`SOLID`描述`应该怎么做`, 后加的规则描述`优先/最好怎么做`.
+
+- `合成/聚合复用原则 (Composition/Aggregation Reuse Principle, CARP)`：应该优先使用对象组合（合成）和聚合，而不是继承来达到代码复用的目的。
+- `迪米特法则 (Law of Demeter, LoD)`：一个对象应该对其他对象有尽可能少的了解，即一个对象应该对其它对象的内部结构和实现细节知道得越少越好。
+
+除了上述提到的常见设计原则外，还有一些其他的设计原则，虽然不如前面提到的那些广为人知，但同样对软件设计和架构有重要的指导作用。 后续提出的这些规则, 有点画蛇添足, 至少我认为它们不反直觉, 不需要深入思考.
+
+- `最少知识原则 (Principle of Least Knowledge, PoLK)`：也被称为迪米特法则的扩展，主张一个对象应该尽可能少地了解其他对象的信息。这个原则的产生可以追溯到 1987 年由帕特里夏·莱塞尔（ Patricia Lago ）和科威特·伯克（ Koos Visser ）提出的“最少通信法则”。
+- `稳定依赖原则 (Stable Dependencies Principle, SDP)`：该原则认为软件设计应该确保稳定的组件不依赖于不稳定的组件，即稳定性较高的组件应该更少地依赖于稳定性较低的组件。这个原则的思想来源于对软件系统中组件之间关系的深入研究。
+- `稳定抽象原则 (Stable Abstraction Principle, SAP)`：与稳定依赖原则相呼应，该原则指导着将抽象性与稳定性相匹配，即稳定的组件应该是抽象的，而不稳定的组件应该是具体的。这个原则有助于确保软件系统的稳定性和灵活性。