定义：软件系统设计时遵循的一套经验性准则，它们共同目的在于预防设计过程中的常见缺陷。这些准则是在长期的软件开发实践中所提炼出来的智慧结晶。
目标：通过这些准则，我们期望能够降低系统的耦合度，提高代码的复用率，增强系统的可靠性，并使得系统更加易于维护。
单一职责原则：一个类应该只承担单一且具体的职责，且其变化原因应尽可能单一。这一原则不仅适用于类，也适用于方法、类库和整个解决方案。
在软件设计中，无论是方法、类、类库还是整个解决方案，都应遵循单一职责原则。例如，一个方法应仅处理一个特定的功能逻辑；一个类应专注于实现一个业务或场景；一个类库可以是专门用于数据库操作、工厂模式、前端组件等。这样的设计有助于保持代码的清晰和可维护性。
开闭原则：这一原则强调对修改关闭，对扩展开放。可以将其视为软件设计的基石，其中开闭原则所指的“开闭”是指抽象与具体的关系，抽象类相当于开放的设计，而具体实现则相当于封闭的修改。
以汽车为例，基础需求是汽车能跑，而追加需求可能是卡车、赛车等不同类型。根据开闭原则，我们应当设计一个抽象的汽车类，并允许通过扩展不同的子类来实现不同的汽车类型，而不必修改已有的代码。
里氏替换原则：在任何父类出现的地方，都应当可以使用其子类，而不会影响程序的正确运行。这一原则强调父类与子类之间的行为约定，包括功能实现、输入输出、异常处理以及注释中的特殊说明等。
迪米特法则（最少知道原则）：一个类应当尽量少地依赖其他类。类的内部逻辑应尽可能封装，只对外提供必要的public方法，露任何不必要的内部信息。
接口依赖原则：客户端不应强制依赖它不需要的接口；类间的依赖关系应建立在最小的接口上。
这一原则要求我们设计接口时需考虑其大小、内聚性及适用范围。过小的接口可以提高内聚性，但若完全遵循此原则可能导致接口数量激增。需要在设计与实用性之间寻找平衡。
依赖倒置原则：上层模块不应当直接依赖下层模块，而是应当依赖其抽象；抽象不应当依赖细节，细节应当依赖抽象。
这一原则通过利用抽象来解耦依赖关系，确保下层模块的修改不会影响到上层模块。
应用场景如人驾驶汽车，我们应优先使用聚合和组合而非继承来降低耦合度。通过以聚合或组合的方式引入接口或抽象类，可以灵活地实现各种子类。
以汽车为例，我们可以按动力源或颜色等多种属性进行分类。尽管分类组合多样，但通过合理的抽象和设计，我们可以保持系统的稳定性和可扩展性。