第一章：面向对象设计原则
SOLID原则是面向对象设计（OOD）中五个基本原则的首字母缩写，由罗伯特·C·马丁（Robert C. Martin，也被称为“Uncle Bob”）提出。它们旨在使软件设计更易于理解、更灵活且更易于维护。遵循这些原则有助于创建出耦合度更低、内聚度更高、更易于测试和扩展的系统。
graph TD
A[SOLID 原则] --> B(S: 单一职责原则 SRP);
A --> C(O: 开闭原则 OCP);
A --> D(L: 里氏替换原则 LSP);
A --> E(I: 接口隔离原则 ISP);
A --> F(D: 依赖倒置原则 DIP);
B --> B1(一个类只负责一项职责);
C --> C1(对扩展开放, 对修改关闭);
D --> D1(子类必须能替换父类);
E --> E1(客户端不应依赖它不需要的接口);
F --> F1(高层模块不应依赖低层模块, 都应依赖抽象);
单一职责原则 (Single Responsibility Principle, SRP)
开闭原则 (Open/Closed Principle, OCP)
里氏替换原则 (Liskov Substitution Principle, LSP)
接口隔离原则 (Interface Segregation Principle, ISP)
依赖倒置原则 (Dependency Inversion Principle, DIP)
请务必谨记，任何原则的运用都需结合项目实际需求灵活变通，深刻理解原则背后的设计思想远比机械地套用条文更为重要。
1.1 单一职责原则 (Single Responsibility Principle, SRP)
核心定义
一个类应该只有一个引起变化的原因，即一个类只负责一项职责。该原则强调将不同的功能分离到不同的类中，避免出现所谓的“上帝类”（God Class）——一个类承担了过多的职责，导致其变得臃肿、难以理解和修改。
深层解读与目的
SRP的核心在于“职责”的划分。这里的职责可以理解为“变化的原因”。如果一个类承担了多个职责，那么当其中一个职责发生变化时，可能会影响到其他职责的实现，从而增加了代码修改的风险和复杂性。
- 降低复杂度：每个类只关注一个特定的功能点，使得类的设计和实现更加简单明了。
- 提高内聚性：类内部的方法和数据都围绕着单一的职责紧密组织。
- 减少耦合：当一个类的职责单一时，它与其他类的依赖关系也会相对简单。
- 增强可读性与可维护性：职责清晰的类更容易被理解，修改一个功能时，影响范围也更小，不易引入新的错误。
- 提高复用性：功能单一、职责明确的类更容易在其他地方被复用。
生活化类比
- 厨房工具：一把菜刀专门用于切菜，一个平底锅专门用于煎炸。如果一把工具试图同时具备切、砍、削、锯、煎、炒、烹、炸所有功能，那它可能会变得非常笨重且每项功能都做得不好。专业的厨师会为不同的任务选择专门的工具。
- 餐厅员工分工：收银员负责收款和结账，服务员负责点餐和上菜，厨师负责烹饪食物，清洁工负责打扫卫生。如果让收银员同时承担烹饪和服务员的工作，不仅效率低下，而且容易出错。
- 瑞士军刀 vs. 专业工具箱：瑞士军刀虽然集成了多种功能，但在特定专业领域，如修理精密仪器，专业的螺丝刀、镊子等独立工具通常更有效。SRP倾向于后者，即每个“工具”（类）都有其明确的专业用途。
实际应用场景
- 用户管理系统：一个
User类如果既负责用户的属性（如用户名、密码），又负责用户的持久化（保存到数据库、从数据库读取），还负责用户信息的校验逻辑，就违反了SRP。可以将其拆分为：User(POJO/Entity)：只包含用户属性和基本getter/setter。UserRepository：负责用户的数据库操作（CRUD）。UserAuthenticator或UserService：负责用户认证、密码校验等业务逻辑。
- 报告生成与数据处理：一个类如果既负责从数据源获取数据，又负责数据的复杂计算和转换，还负责将结果格式化为报告（如PDF、Excel），则职责过多。应拆分为数据获取类、数据处理/计算类、报告生成类。
- UI与业务逻辑：在图形用户界面（GUI）应用中，一个界面类如果既处理用户输入事件、更新界面显示，又执行核心的业务计算和数据操作，就违反了SRP。应将业务逻辑分离到专门的服务类或逻辑处理类中。
作用与价值
| 作用维度 | 具体表现 |
|---|---|
| 降低复杂度 | 每个类的代码量减少，逻辑更集中，易于理解。 |
| 提高可读性 | 职责清晰的类名和方法名使得代码意图更明确。 |
| 增强可维护性 | 修改一个功能时，只需关注相关的少数类，减少了对系统其他部分的影响。 |
| 提高复用性 | 职责单一的类更容易被其他模块或项目复用。 |
| 降低耦合度 | 类之间的依赖关系更简单，一个类的变化不容易引起其他类的连锁反应。 |
| 易于测试 | 职责单一的类更容易进行单元测试，因为其依赖和行为更可控。 |
代码示例 (Java)
违反SRP的例子：
// 违反SRP: UserSettingService 同时负责用户设置的获取、修改以及邮件通知
class UserSettingService_Bad {
private String userId;
public UserSettingService_Bad(String userId) {
this.userId = userId;
}
public String getPreference(String key) {
// 模拟从数据库获取用户偏好设置
System.out.println("Getting preference '" + key + "' for user " + userId);
return "value_for_" + key;
}
public void setPreference(String key, String value) {
// 模拟向数据库保存用户偏好设置
System.out.println("Setting preference '" + key + "' to '" + value + "' for user " + userId);
// 假设设置成功后需要发送邮件通知
sendEmailNotification("Preference Updated", "Your preference '" + key + "' has been updated.");
}
// 邮件通知功能，与用户设置的核心职责不同
public void sendEmailNotification(String subject, String body) {
System.out.println("Sending email to user " + userId + ": Subject='" + subject + "', Body='" + body + "'");
// ... 实际的邮件发送逻辑 ...
}
}
在UserSettingService_Bad中，如果邮件发送逻辑需要修改（例如，更换邮件服务提供商，或修改邮件模板），会导致UserSettingService_Bad类发生变化，即使核心的用户设置存取逻辑并未改变。这表明它承担了多个引起变化的原因。
遵循SRP的例子：
// 职责1: 用户设置的存储和获取
class UserPreferenceRepository {
private String userId;
public UserPreferenceRepository(String userId) {
this.userId = userId;
}
public String getPreference(String key) {
System.out.println("Repository: Getting preference '" + key + "' for user " + userId);
return "value_for_" + key;
}
public void setPreference(String key, String value) {
System.out.println("Repository: Setting preference '" + key + "' to '" + value + "' for user " + userId);
}
}
// 职责2: 邮件通知服务
class EmailService {
public void sendEmail(String recipientId, String subject, String body) {
System.out.println("EmailService: Sending email to user " + recipientId + ": Subject='" + subject + "', Body='" + body + "'");
// ... 实际的邮件发送逻辑 ...
}
}
// 协调类 (或者应用服务层)
class UserSettingService_Good {
private UserPreferenceRepository preferenceRepository;
private EmailService emailService;
private String userId;
public UserSettingService_Good(String userId, UserPreferenceRepository preferenceRepository, EmailService emailService) {
this.userId = userId;
this.preferenceRepository = preferenceRepository;
this.emailService = emailService;
}
public String getPreference(String key) {
return preferenceRepository.getPreference(key);
}
public void setPreference(String key, String value) {
preferenceRepository.setPreference(key, value);
// 业务流程中决定是否发送邮件
emailService.sendEmail(this.userId, "Preference Updated", "Your preference '" + key + "' has been updated.");
}
}
// 使用示例
// UserPreferenceRepository repo = new UserPreferenceRepository("user123");
// EmailService mailer = new EmailService();
// UserSettingService_Good service = new UserSettingService_Good("user123", repo, mailer);
// service.setPreference("theme", "dark");
在这个遵循SRP的例子中：
UserPreferenceRepository只负责用户偏好设置的持久化逻辑。EmailService只负责发送邮件的逻辑。UserSettingService_Good负责协调这两个服务来完成业务流程，但它本身不直接实现持久化或邮件发送的细节。
现在，如果邮件发送逻辑需要修改，只需要改动EmailService。如果持久化方式需要改变，只需要改动UserPreferenceRepository。UserSettingService_Good的职责是业务流程编排，相对稳定。
优缺点
| 优点 | 缺点 |
|---|---|
| 降低了类的复杂度，提高了类的可读性。 | 可能导致类的数量增加：将一个复杂的类拆分成多个小类，会增加系统中的类总数，有时可能会让系统结构在宏观上显得更分散。 |
| 提高了系统的可维护性。 | 职责划分的主观性：“职责”的粒度有时难以界定，过度拆分可能导致类过于细碎，反而增加理解成本。 |
| 增强了类的内聚性，降低了耦合度。 | 增加了类之间的通信成本：原本在一个类内部的方法调用，拆分后可能变成类与类之间的调用。 |
| 提高了代码的复用性。 | |
| 变更风险降低。 |
最佳实践与应用指南
- 识别变化的原因：思考哪些变化会影响到这个类。如果一个类有多个独立的变化轴，那么它可能承担了多个职责。
- 职责的粒度要适中：职责划分得过细，会导致类数量剧增，增加系统的复杂性；划分得过粗，则达不到SRP的目的。需要根据具体业务场景和团队理解来权衡。
- “能用一句话清晰描述类的职责吗？”：如果不能，或者需要用“和”、“或”等连接词来描述多个不相关的功能，那么这个类可能违反了SRP。
- 关注点分离 (Separation of Concerns, SoC)：SRP是SoC在类级别的一个体现。将不同的关注点分离到不同的模块或类中。
- 逐步演进：在项目初期，某些类可能因为简单而承担了略微多一点的职责。随着业务的发展和复杂性的增加，可以逐步对这些类进行重构，以更好地遵循SRP。
- 与业务领域对齐：类的职责划分应尽可能与业务领域的概念和流程保持一致，这样更容易被业务人员和开发人员共同理解。
单一职责原则是构建高质量软件的基础。虽然“职责”的界定需要经验和判断，但其核心思想——让每个类只做好一件事——对于创建清晰、可维护的系统至关重要。
1.2 开闭原则 (Open/Closed Principle, OCP)
核心定义
开闭原则（Open/Closed Principle, OCP）指出，软件实体（如类、模块、函数等）应该对于扩展是开放的，但是对于修改是关闭的。 这意味着当软件系统需要增加新的功能时，我们应该通过增加新的代码来实现，而不是修改已有的、经过测试的旧代码。
深层解读与目的
OCP是面向对象设计中最重要、最核心的原则之一，其目标在于使系统在面对需求变化时保持稳定，同时易于扩展。
- 对扩展开放 (Open for Extension)：意味着模块的行为是可以扩展的。当应用的需求改变或增加新功能时，我们可以对模块进行扩展，使其具有新的行为以满足新的需求。
- 对修改关闭 (Closed for Modification)：意味着一旦一个模块开发完成并通过测试，就不应该再修改其源代码。如果允许修改，那么之前所做的所有测试都可能失效，并且可能引入新的错误到现有功能中。
实现开闭原则的关键在于抽象化。通过定义抽象的接口或基类，高层模块依赖于这些抽象，而具体的实现则由低层模块来完成。当需要扩展功能时，我们只需要创建新的具体实现类（继承抽象类或实现接口），而不需要修改依赖于抽象的高层模块代码，也不需要修改抽象本身。
遵循OCP的好处：
- 提高系统的可维护性：由于现有代码不被修改，减少了引入错误的风险，降低了维护成本。
- 增强系统的灵活性和可扩展性：新功能的增加通过添加新模块实现，系统可以轻松适应需求变化。
- 提高代码的复用性：抽象层可以被不同的具体实现复用。
- 降低回归测试的成本和范围：由于核心代码未变，测试主要集中在新添加的模块上。
生活化类比
- USB接口的电脑：电脑的USB接口是"对修改关闭"的（你不能轻易改变USB接口的物理规格和基本协议）。但是它是"对扩展开放"的，你可以插入各种USB设备（U盘、鼠标、键盘、打印机等）来扩展电脑的功能，而无需修改电脑主板。
- 智能手机应用商店：手机操作系统本身（核心功能）是相对稳定的（对修改关闭）。用户可以通过应用商店下载安装新的App来获得各种新功能（对扩展开放），而不需要修改操作系统源码。
- 电源插座和电器：墙上的电源插座标准是固定的（对修改关闭）。你可以插入任何符合该标准的电器（如台灯、电视、充电器）来使用电力（对扩展开放），而无需改动墙内的电线或插座本身。
实际应用场景
- 支付系统：一个电商系统需要支持多种支付方式（如支付宝、微信支付、银行卡支付）。可以定义一个
PaymentStrategy接口，包含pay()方法。每种支付方式都是这个接口的一个具体实现。当需要增加新的支付方式（如Apple Pay）时，只需新增一个ApplePayStrategy类实现PaymentStrategy接口，而无需修改订单处理模块或PaymentStrategy接口本身。 - 图形界面皮肤切换：一个应用软件需要支持多种界面皮肤。可以定义一个
Skin抽象类或接口，不同的皮肤是其具体子类。用户切换皮肤时，系统加载不同的Skin子类实例即可，无需修改界面渲染的核心逻辑。 - 日志记录：系统可能需要将日志记录到文件、数据库或发送到远程服务器。可以定义一个
Logger接口，不同的记录方式是其具体实现。当需要增加新的日志记录方式时，只需添加新的实现类。 - 数据导出功能：系统需要将数据导出为不同格式（CSV, Excel, PDF）。可以定义一个
DataExporter接口，每种格式的导出器是其实现。新增导出格式时，添加新的实现类即可。
作用与价值
| 作用维度 | 具体表现 |
|---|---|
| 提高可维护性 | 修改关闭意味着现有稳定代码不受影响，减少了因修改引入错误的风险。 |
| 增强可扩展性 | 对扩展开放使得系统可以方便地增加新功能，适应需求变化。 |
| 提升代码复用性 | 通过抽象和多态，可以复用高层模块逻辑，仅替换或增加具体实现。 |
| 降低耦合度 | 高层模块依赖于抽象，与具体实现解耦，使得系统各部分更加独立。 |
| 减少回归测试压力 | 由于核心代码未变动，测试工作可以更集中于新增的扩展部分。 |
| 促进架构稳定性 | 鼓励面向接口编程，使得系统架构在面对变化时更加稳固。 |
代码示例 (Java)
场景：图形编辑器根据不同形状绘制图形。
违反OCP的例子：
// 图形类型枚举
enum ShapeType {
CIRCLE, RECTANGLE // 如果要增加三角形，需要修改这里
}
class GraphicEditor_Bad {
public void drawShape(ShapeType type) {
if (type == ShapeType.CIRCLE) {
drawCircle();
} else if (type == ShapeType.RECTANGLE) {
drawRectangle();
} // 如果要增加三角形，需要在这里增加一个else if分支，修改了原有代码
}
private void drawCircle() {
System.out.println("Drawing a circle");
}
private void drawRectangle() {
System.out.println("Drawing a rectangle");
}
}
// 使用
// GraphicEditor_Bad editorBad = new GraphicEditor_Bad();
// editorBad.drawShape(ShapeType.CIRCLE);
在GraphicEditor_Bad中，每当需要支持新的图形时，都必须修改drawShape方法和ShapeType枚举，这违反了开闭原则。
遵循OCP的例子：
// 步骤1: 创建一个抽象的图形接口/基类
interface Shape {
void draw();
}
// 步骤2: 为每种具体的图形创建实现类
class Circle implements Shape {
@Override
public void draw() {
System.out.println("Drawing a circle using OCP");
}
}
class Rectangle implements Shape {
@Override
public void draw() {
System.out.println("Drawing a rectangle using OCP");
}
}
// 新增图形类型，例如三角形，只需新增一个类
class Triangle implements Shape {
@Override
public void draw() {
System.out.println("Drawing a triangle using OCP");
}
}
// 步骤3: 图形编辑器依赖于抽象的Shape接口
class GraphicEditor_Good {
public void drawShape(Shape s) {
s.draw(); // 调用抽象方法，无需关心具体类型，原有代码不需修改
}
}
// 使用
// GraphicEditor_Good editorGood = new GraphicEditor_Good();
// Shape circle = new Circle();
// Shape rectangle = new Rectangle();
// Shape triangle = new Triangle(); // 新增的图形
// editorGood.drawShape(circle);
// editorGood.drawShape(rectangle);
// editorGood.drawShape(triangle); // 编辑器可以无缝处理新图形
在这个遵循OCP的例子中，GraphicEditor_Good类依赖于Shape抽象。当需要添加新的图形（如Triangle）时，我们只需要创建一个新的类实现Shape接口，而GraphicEditor_Good的代码完全不需要修改。这就是"对扩展开放，对修改关闭"。
优缺点
| 优点 | 缺点 |
|---|---|
| 提高系统的稳定性和灵活性。 | 可能增加代码的复杂性：为了实现开闭原则，可能需要引入更多的抽象和间接层，导致类的数量增加，结构可能变得更复杂。 |
| 增强代码的可复用性。 | 预测变化的困难性：并非所有变化都能被预见。如果对不常变化或难以预见变化的部分过度应用OCP，可能会导致过度设计。 |
| 提高系统的可维护性，降低维护成本。 | 需要更高的设计技巧：正确地识别出系统的变化点并进行恰当的抽象，对设计者的经验和能力有较高要求。 |
| 易于进行单元测试。 |
最佳实践与应用指南
- 识别变化点：在设计之初，要仔细分析需求，找出系统中哪些部分是可能发生变化的，哪些部分是相对稳定的。OCP主要应用于这些易变的部分。
- 创建抽象：针对变化点，通过接口、抽象类等方式创建抽象层，将变化的部分封装在具体的实现类中。
- 面向接口编程：高层模块应依赖于抽象（接口或抽象类），而不是具体的实现类。
- 使用设计模式：许多设计模式（如策略模式、观察者模式、装饰者模式、模板方法模式、工厂模式等）都是OCP思想的具体体现，可以帮助我们更好地实现开闭原则。
- 策略模式：允许在运行时改变算法或行为，非常适合实现OCP。
- 模板方法模式：定义一个操作中的算法骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
- 避免过度设计：不要为了遵循OCP而对系统中所有部分都进行抽象。应权衡利弊，只在确实需要灵活性和可扩展性的地方应用。
- 增量式应用：对于现有系统，可以在进行新功能开发或重构时，逐步引入OCP的思想，而不是试图一次性改造整个系统。
- 依赖注入 (Dependency Injection)：DI容器可以帮助管理对象之间的依赖关系，使得替换具体实现更加容易，从而支持OCP。
开闭原则是实现高质量、可维护、可扩展软件系统的关键。通过合理的抽象和封装，我们可以构建出能够从容应对需求变化的健壮系统。
1.3 里氏替换原则 (Liskov Substitution Principle, LSP)
核心定义
里氏替换原则（Liskov Substitution Principle, LSP）由Barbara Liskov在1987年提出，其核心思想是：所有引用基类（父类）的地方必须能够透明地使用其子类的对象，而程序行为不发生改变。 简单来说，子类必须能够替换掉它们的父类，并且替换后程序的逻辑行为保持一致。
更形式化的定义是：如果对于每个类型S的对象o1，都有类型T的对象o2，使得对于所有用T定义的操作P，当o1取代o2时，P的行为没有变化，那么S是T的子类型。
深层解读与目的
LSP是保证继承体系正确性的重要原则，它强调了子类与父类之间行为上的一致性，是实现开闭原则的重要方式之一。
- 行为一致性：子类在继承父类时，不应该改变父类已有的行为和契约。子类可以增加新的行为，但不能修改或废弃父类的行为，尤其是那些被客户端依赖的行为。
- “IS-A”关系的真正含义：LSP强调继承表达的是一种“IS-A”的行为关系，而不仅仅是结构上的相似。子类“是”一个父类，意味着子类对象在任何父类对象出现的地方都应该能正常工作。
- 防止继承滥用：如果子类不能完全替换父类，那么这种继承关系可能是不恰当的，可能会导致程序在运行时出现意外错误。
遵循LSP的好处：
- 增强代码的健壮性：客户端代码可以安全地使用父类引用指向子类对象，而不必担心子类会破坏原有的逻辑。
- 提高代码的可复用性：父类和子类都可以被更广泛地复用。
- 促进多态的正确使用：LSP是多态能够正确发挥作用的基础。
- 使继承体系更合理：避免了不符合“IS-A”行为关系的继承。
生活化类比
- 鸟类与企鹅：如果有一个
Bird类，它有一个fly()方法。Penguin类继承自Bird。但企鹅不会飞。如果Penguin的fly()方法实现为抛出异常或什么都不做，那么当客户端代码期望一只“鸟”能飞时，传入一个企鹅对象就会出问题。这违反了LSP。正确的做法可能是将fly()方法从Bird基类移到更具体的FlyingBird子类中，或者让Bird有一个更通用的move()方法。 - 长方形与正方形：经典的例子。如果
Square类继承自Rectangle类。Rectangle有setWidth()和setHeight()方法。如果Square为了保持四边相等，在setWidth()时同时修改了height（反之亦然），那么当客户端代码期望设置一个长方形的宽度而不改变其高度时，传入一个正方形对象就会导致行为不一致。这也违反了LSP。 - 遥控器与电视/空调：一个通用遥控器（父类接口）设计用来控制多种设备。如果一个电视遥控器（子类）实现了这个通用接口，那么用户在使用通用遥控器控制电视时，其行为（如开关、换台、调音量）应该与预期一致。如果电视遥控器在“换台”按钮上实现了“切换输入源”的功能，就违反了LSP。
实际应用场景
- 集合类的继承：Java中的
Properties类继承自Hashtable。Hashtable允许存储任何类型的键和值，而Properties主要用于存储字符串类型的键值对。虽然Properties可以存储非字符串，但其设计意图和常用API（如getProperty,setProperty）都是针对字符串的。如果一个方法期望接收一个Hashtable并存入非字符串键值，而传入的是一个Properties实例，后续使用Properties的特定方法时可能会出现问题，这在某种程度上是LSP的一个警示。 - 覆盖父类方法时的约束：
- 子类方法的前置条件（preconditions）必须与父类方法的前置条件相同或更宽松。
- 子类方法的后置条件（postconditions）必须与父类方法的后置条件相同或更严格。
- 子类方法抛出的异常类型必须与父类方法抛出的异常类型相同或是其子类型。
- 子类方法的参数类型可以是父类方法参数类型的父类型（逆变）。
- 子类方法的返回类型可以是父类方法返回类型的子类型（协变）。
- 避免在子类中重写父类方法并使其抛出新的、父类未声明的受检异常。
作用与价值
| 作用维度 | 具体表现 |
|---|---|
| 保证继承的正确性 | 确保子类在行为上真正是父类的一种特殊化，而不是破坏父类的契约。 |
| 增强代码健壮性 | 客户端可以放心地使用父类引用操作子类对象，减少运行时错误。 |
| 提高可维护性 | 代码行为更可预测，修改和调试更容易。 |
| 促进多态的有效性 | 是多态能够按预期工作的基石。 |
| 指导继承设计 | 帮助开发者判断何时应该使用继承，何时应该考虑组合或其他关系。 |
代码示例 (Kotlin)
场景：一个计算面积的程序。
违反LSP的例子 (经典的正方形继承长方形问题)：
open class Rectangle_LSP_Bad {
open var width: Double = 0.0
open var height: Double = 0.0
open fun setDimensions(w: Double, h: Double) {
this.width = w
this.height = h
}
open fun getArea(): Double {
return width * height
}
}
class Square_LSP_Bad : Rectangle_LSP_Bad() {
// 为了保持正方形的特性，重写setter
override var width: Double
get() = super.width
set(value) {
super.width = value
super.height = value // 改变了height的行为
}
override var height: Double
get() = super.height
set(value) {
super.height = value
super.width = value // 改变了width的行为
}
// 或者重写setDimensions
// override fun setDimensions(w: Double, h: Double) {
// if (w != h) throw IllegalArgumentException("Square sides must be equal")
// super.setDimensions(w, h)
// }
}
fun printArea_LSP_Bad(rectangle: Rectangle_LSP_Bad) {
rectangle.setDimensions(5.0, 4.0) // 期望设置宽度为5，高度为4
// 对于Rectangle实例，面积是20
// 对于Square实例，如果setDimensions(5,4)时，width和height都变成4（或5），或者抛异常，行为与Rectangle不一致
println("Area: ${rectangle.getArea()}")
// 如果传入Square, width=4, height=4, area=16 (假设以最后一个参数为准)
// 或者 width=5, height=5, area=25 (假设以第一个参数为准)
// 这与客户端对Rectangle行为的期望（width=5, height=4, area=20）不符
}
// 使用
// val rect = Rectangle_LSP_Bad()
// val square = Square_LSP_Bad()
// printArea_LSP_Bad(rect) // 输出: Area: 20.0 (符合预期)
// printArea_LSP_Bad(square) // 输出可能不是20.0，或者抛异常，违反LSP
在这个例子中，Square_LSP_Bad继承了Rectangle_LSP_Bad。客户端代码printArea_LSP_Bad期望通过setDimensions(5.0, 4.0)设置一个宽度为5、高度为4的矩形。但如果传入的是Square_LSP_Bad实例，由于其内部逻辑要保持宽高相等，setDimensions的行为会与父类不一致（例如，它可能将宽高都设为4，或都设为5，或抛出异常），导致getArea()的结果也与预期不符。
遵循LSP的例子 (通常通过不使用继承，或更抽象的基类来解决)：
一种常见的解决方案是不让Square继承Rectangle，或者它们都继承自一个更抽象的Shape类。
interface Shape_LSP_Good {
fun getArea(): Double
}
class Rectangle_LSP_Good(private var width: Double, private var height: Double) : Shape_LSP_Good {
fun setWidth(w: Double) { this.width = w }
fun setHeight(h: Double) { this.height = h }
override fun getArea(): Double = width * height
}
class Square_LSP_Good(private var side: Double) : Shape_LSP_Good {
fun setSide(s: Double) { this.side = s }
override fun getArea(): Double = side * side
}
fun printShapeArea_LSP_Good(shape: Shape_LSP_Good) {
// 这里不能假设shape有setWidth或setHeight，因为Shape_LSP_Good接口没有定义它们
// 客户端只能依赖Shape_LSP_Good接口中定义的方法
println("Shape Area: ${shape.getArea()}")
}
// 使用
// val rectGood = Rectangle_LSP_Good(5.0, 4.0)
// val squareGood = Square_LSP_Good(5.0)
// printShapeArea_LSP_Good(rectGood) // 输出: Shape Area: 20.0
// printShapeArea_LSP_Good(squareGood) // 输出: Shape Area: 25.0
// 这种情况下，客户端与Shape_LSP_Good交互，行为是一致的（都能获取面积）
如果确实需要一个可以设置宽高的共同基类，并且要包含正方形，那么设计需要更小心，确保子类行为不违反父类契约。通常，如果子类对父类方法的行为施加了比父类更强的约束（如正方形要求宽高相等），就很容易违反LSP。
优缺点
| 优点 | 缺点 |
|---|---|
| 保证了继承体系的正确性和健壮性。 | 可能限制继承的灵活性：过于严格地遵循LSP，有时可能会使得一些看似合理的继承关系变得不可能，迫使开发者寻找其他设计方案。 |
| 提高了代码的可复用性和可维护性。 | 判断行为一致性可能复杂：在复杂场景下，准确判断子类行为是否完全符合父类契约可能比较困难。 |
| 是实现开闭原则的重要保证。 | 可能导致继承层次更深或更复杂：为了满足LSP，可能需要引入更多的抽象层或中间类。 |
| 避免了因不当继承引入的运行时错误。 |
最佳实践与应用指南
- 子类必须实现父类的所有抽象方法，但不得重写（覆盖）父类的非抽象（具体）方法，除非是为了扩展而非改变原有行为。 （这条比较严格，实际中重写具体方法很常见，关键是行为要一致）。
- 子类可以增加自己特有的方法。
- 当子类的方法重写父类的方法时，方法的前置条件（即方法的输入/参数）要比父类方法的输入参数更宽松或相同。
- 当子类的方法重写父类的方法时，方法的后置条件（即方法的输出/返回值）要比父类方法的输出更严格或相同。
- 子类不应该抛出比父类方法声明的异常更多或更宽泛的异常类型。
- 仔细思考“IS-A”关系：在决定使用继承之前，问自己子类是否真的“是”一个父类，并且在所有行为上都能表现得像父类。
- 优先使用组合和委托而非继承：如果LSP难以满足，通常表明继承可能不是最佳选择，可以考虑使用对象组合来复用功能。
- 进行充分的单元测试：确保子类在替换父类后，原有的测试用例依然能够通过。
- 避免在子类中覆盖父类方法并使其实现为空或抛出
UnsupportedOperationException，除非父类本身就明确声明了该方法是可选的（例如通过接口的默认方法或抽象类的空实现）。
里氏替换原则是面向对象设计中一个深刻且关键的原则。它要求我们从行为的角度去审视继承关系，确保子类能够真正地替代父类，从而构建出更加稳健和可靠的软件系统。
1.4 接口隔离原则 (Interface Segregation Principle, ISP)
核心定义
接口隔离原则（Interface Segregation Principle, ISP）指出，客户端不应该被迫依赖于它们不使用的方法。 或者说，类间的依赖关系应该建立在最小的接口上。这意味着一个类对另一个类的依赖应该建立在最小的接口上，不应该强迫一个类实现它不需要的接口方法。
深层解读与目的
ISP的核心思想是“小而专”的接口优于“大而全”的接口。当一个接口包含了太多方法，而某些实现类只需要其中的一部分方法时，就会导致这些类被迫实现它们用不到的方法（通常是空实现或抛出不支持操作的异常），这会增加系统的复杂性和耦合度。
- 接口污染：如果一个接口过于臃肿（fat interface），包含了客户端不需要的方法，那么实现该接口的类就会受到“污染”，因为它必须为那些不相关的方法提供实现。
- 降低耦合：通过将大接口拆分成多个更小、更具体的接口，客户端可以只依赖于它们真正需要的接口。这样，当一个接口发生变化时，只有依赖于该特定接口的客户端才会受到影响，其他客户端则不受干扰。
- 提高内聚性：小接口通常具有更高的内聚性，因为它们只包含一组相关的方法，专注于单一的职责或功能。
- 增强灵活性和可维护性：系统更容易修改和扩展，因为接口的职责更清晰，修改一个接口的影响范围更小。
遵循ISP的好处：
- 避免接口污染，保持接口的纯洁性。
- 提高系统的灵活性和可维护性。
- 降低类之间的耦合度。
- 接口的职责更清晰，更易于理解和使用。
生活化类比
- 餐厅菜单：一个好的餐厅可能会提供不同的菜单给不同需求的顾客。例如，为素食者提供素食菜单，为儿童提供儿童菜单，而不是给所有顾客一本包含所有菜品（肉类、素食、儿童餐、甜点、酒水等）的巨大菜单。顾客只需要关心他们感兴趣的那部分菜单。
- 多功能遥控器 vs. 专用遥控器：一个万能遥控器可能有很多按钮，对应电视、DVD播放器、音响等多种设备。但如果你只需要控制电视，那么很多按钮都是多余的。一个只包含电视控制按钮的专用遥控器对你来说更简洁易用。
- 瑞士军刀：虽然瑞士军刀功能很多，但如果你只是想开瓶盖，那么一个简单的开瓶器可能更合适，你不需要被迫携带一把包含剪刀、螺丝刀、锯子等的复杂工具。
实际应用场景
- 用户权限管理：一个系统可能有多种用户角色，如管理员、编辑、普通用户。如果定义一个统一的
IUserOperation接口包含所有可能的操作（如createUser(),editArticle(),viewContent(),deleteUser()), 那么普通用户类在实现这个接口时，对于createUser()和deleteUser()等方法就只能空实现或抛异常。更好的做法是拆分成IAdminOperation,IEditorOperation,IViewerOperation等小接口。 - 打印机功能：一个老式的多功能一体机可能有一个包含打印、扫描、复印、传真所有功能的接口。但如果一个新的智能打印机只支持打印和扫描，它就不应该被迫实现复印和传真的接口方法。可以将接口拆分为
IPrinter,IScanner,ICopier,IFax。 - 动物行为：假设有一个
IAnimal接口，包含eat(),sleep(),fly(),swim()。对于鸟类，fly()是适用的，但swim()可能不适用（除非是水禽）。对于鱼类，swim()适用，但fly()不适用。将行为拆分为IFlyable,ISwimmable等接口更为合适。
作用与价值
| 作用维度 | 具体表现 |
|---|---|
| 降低耦合度 | 客户端只依赖于其需要的方法，减少了不必要的依赖。 |
| 提高内聚性 | 每个接口都服务于一个特定的客户端群体或一个特定的功能集，职责更单一。 |
| 增强系统灵活性 | 当需求变化时，修改小接口的影响范围更小，系统更容易适应变化。 |
| 提高代码可读性 | 接口更小、更专注，使得代码更容易理解和维护。 |
| 避免接口污染 | 实现类不需要实现它们用不到的方法，代码更简洁。 |
| 促进并行开发 | 不同的开发团队可以基于不同的小接口并行工作。 |
代码示例 (Java)
场景：一个智能设备接口，包含多种功能。
违反ISP的例子：
// 一个臃肿的智能设备接口
interface ISmartDevice_Bad {
void turnOn();
void turnOff();
void playMusic();
void stopMusic();
void takePhoto();
void recordVideo();
// ... 可能还有更多不相关的方法
}
// 一个简单的智能灯泡，它只需要开关功能，但被迫实现所有方法
class SmartLight_Bad implements ISmartDevice_Bad {
@Override
public void turnOn() { System.out.println("Light is ON"); }
@Override
public void turnOff() { System.out.println("Light is OFF"); }
// 以下方法对智能灯泡无意义，被迫空实现或抛异常
@Override
public void playMusic() { /* Not supported */ }
@Override
public void stopMusic() { /* Not supported */ }
@Override
public void takePhoto() { /* Not supported */ }
@Override
public void recordVideo() { /* Not supported */ }
}
// 一个智能音箱，它不需要拍照和录像功能
class SmartSpeaker_Bad implements ISmartDevice_Bad {
@Override
public void turnOn() { System.out.println("Speaker is ON"); }
@Override
public void turnOff() { System.out.println("Speaker is OFF"); }
@Override
public void playMusic() { System.out.println("Playing music"); }
@Override
public void stopMusic() { System.out.println("Music stopped"); }
// 以下方法对智能音箱无意义
@Override
public void takePhoto() { /* Not supported */ }
@Override
public void recordVideo() { /* Not supported */ }
}
SmartLight_Bad和SmartSpeaker_Bad都被迫实现了它们不需要的方法。
遵循ISP的例子：
// 步骤1: 将大接口拆分成多个小而专的接口
interface IPowerControllable {
void turnOn();
void turnOff();
}
interface IMusicPlayable {
void playMusic();
void stopMusic();
}
interface ICameraFunctions {
void takePhoto();
void recordVideo();
}
// 步骤2: 设备类只实现它们真正需要的接口
class SmartLight_Good implements IPowerControllable {
@Override
public void turnOn() { System.out.println("Smart Light is ON"); }
@Override
public void turnOff() { System.out.println("Smart Light is OFF"); }
}
class SmartSpeaker_Good implements IPowerControllable, IMusicPlayable {
@Override
public void turnOn() { System.out.println("Smart Speaker is ON"); }
@Override
public void turnOff() { System.out.println("Smart Speaker is OFF"); }
@Override
public void playMusic() { System.out.println("Smart Speaker playing music"); }
@Override
public void stopMusic() { System.out.println("Smart Speaker music stopped"); }
}
class SmartCamera_Good implements IPowerControllable, ICameraFunctions {
@Override
public void turnOn() { System.out.println("Smart Camera is ON"); }
@Override
public void turnOff() { System.out.println("Smart Camera is OFF"); }
@Override
public void takePhoto() { System.out.println("Smart Camera took a photo"); }
@Override
public void recordVideo() { System.out.println("Smart Camera recording video"); }
}
// 客户端代码可以根据需要的接口类型来操作设备
// void controlPower(IPowerControllable device) {
// device.turnOn();
// }
// void operateMusic(IMusicPlayable musicDevice) {
// musicDevice.playMusic();
// }
在这个遵循ISP的例子中，SmartLight_Good只实现了IPowerControllable接口，SmartSpeaker_Good实现了IPowerControllable和IMusicPlayable接口。它们不再需要实现不相关的方法。
优缺点
| 优点 | 缺点 |
|---|---|
| 降低了类间的耦合度。 | 可能导致接口数量过多：过度拆分接口可能会使得系统中的接口数量剧增，增加管理的复杂性。 |
| 提高了系统的内聚性。 | 需要仔细规划接口粒度：如何恰当地拆分接口，拆分到什么程度，需要设计者仔细权衡。 |
| 增强了系统的灵活性和可维护性。 | |
| 避免了接口污染，代码更清晰。 | |
| 有利于并行开发和单元测试。 |
最佳实践与应用指南
- 接口尽量小：一个接口应该只包含一组密切相关的方法。如果一个接口包含了过多的方法，考虑将其拆分。
- 根据客户端需求设计接口：接口的设计应该服务于客户端，而不是强迫客户端去适应一个臃肿的接口。不同的客户端可能有不同的需求，可能需要不同的接口。
- 使用委托模式和适配器模式：当一个类需要实现多个不相关的接口时，可以考虑使用委托模式将不同接口的实现委托给不同的内部对象。当需要适配一个现有类到一个不兼容的接口时，可以使用适配器模式，并且适配器可以只暴露客户端需要的接口部分。
- 避免“胖接口”（Fat Interface）：时刻警惕接口是否包含了过多的方法，导致实现类承担了不必要的责任。
- 单一职责原则（SRP）可以指导接口设计：虽然SRP主要应用于类，但其思想也可以借鉴到接口设计上，即一个接口也应该有单一的职责或目的。
- 优先使用多个特定的小接口，而不是一个通用的大接口。
- 对于已有的大接口，如果不能直接修改，可以考虑使用适配器模式（Adapter Pattern）来提供一个更小、更专用的接口给客户端。
接口隔离原则鼓励我们设计出更小、更专注的接口，从而构建出更松耦合、更易于维护和扩展的系统。它是面向对象设计中保持系统清晰和灵活的重要手段。
1.5 依赖倒置原则 (Dependency Inversion Principle, DIP)
核心定义
依赖倒置原则（Dependency Inversion Principle, DIP）指出：
- 高层模块不应该依赖于低层模块。两者都应该依赖于抽象。
- 抽象不应该依赖于细节。细节应该依赖于抽象。
简单来说，DIP要求我们在设计系统时，要依赖于抽象接口或抽象类，而不是依赖于具体的实现类。这种“倒置”指的是传统软件设计中高层模块调用低层模块，依赖关系是自上而下的；而DIP则通过引入抽象层，使得高层和低层都依赖于这个抽象层，依赖关系的方向发生了“倒置”。
深层解读与目的
DIP是实现松耦合系统架构的关键原则之一，其核心目的是减少模块间的直接依赖，特别是高层业务逻辑对低层实现细节的依赖，从而提高系统的灵活性、可维护性和可测试性。
- 高层模块 vs. 低层模块：高层模块通常包含系统的核心业务逻辑和策略，它们定义了系统应该做什么。低层模块则包含实现这些策略所需的具体机制和细节，例如数据库访问、文件操作、网络通信等。
- 依赖于抽象：抽象通常指接口（Interface）或抽象类（Abstract Class）。高层模块定义它所需要的服务接口，而低层模块则提供这些接口的具体实现。这样，高层模块只知道它需要一个符合某种契约的服务，而不需要关心这个服务是如何实现的。
- 控制反转 (Inversion of Control, IoC)：DIP是IoC思想的一个具体体现。传统的流程控制是高层模块主动创建和调用低层模块。而在IoC中，创建和管理低层模块（依赖对象）的控制权从高层模块中移出，通常由外部容器或框架（如Spring的DI容器）来负责，或者通过构造函数注入、Setter注入等方式将依赖传递给高层模块。
- 面向接口编程：DIP鼓励“面向接口编程，而不是面向实现编程”。
遵循DIP的好处：
- 降低耦合度：高层模块和低层模块之间的耦合通过抽象层解开，修改低层模块的实现细节不会影响到高层模块。
- 提高系统的灵活性和可扩展性：可以方便地替换低层模块的具体实现，只要新的实现遵循相同的抽象接口即可。
- 增强代码的可测试性：在测试高层模块时，可以很容易地使用模拟对象（Mock Objects）或存根（Stubs）来替代真实的低层模块，从而实现单元测试的隔离。
- 促进并行开发：一旦抽象接口定义好，高层模块和低层模块的开发可以并行进行。
生活化类比
- 电源插座和电器 (再次出现)：电器（高层模块，如台灯、电脑）并不直接依赖于某个特定的发电厂（低层模块）。它们都依赖于一个标准的电源插座接口和电压标准（抽象）。只要发电厂能提供符合标准的电力并通过插座输出，任何电器都可以使用。发电厂的实现方式（火电、水电、核电）对电器来说是透明的。
- 汽车和轮胎：汽车制造商（高层模块）在设计汽车时，不会指定必须使用米其林轮胎或普利司通轮胎（低层模块的具体实现）。相反，他们会定义轮胎的规格标准（如尺寸、承重、速度级别等——抽象接口）。任何符合这些标准的轮胎都可以安装到汽车上。车主可以根据自己的需求更换不同品牌的轮胎。
- 老板和员工：老板（高层模块）需要完成一项任务（如市场调研）。老板不会直接去执行具体的调研步骤（低层细节），而是定义任务的需求和期望结果（抽象），然后将任务分配给具备相应能力的员工或团队（低层模块的实现）。员工如何完成任务（具体方法）对老板来说不重要，只要结果符合要求。
实际应用场景
- 业务逻辑层与数据访问层：业务逻辑层（高层）不应该直接依赖于具体的数据库访问技术（如直接使用JDBC API或特定ORM框架的API）。应该定义一个数据访问接口（如
UserRepository接口），业务逻辑层依赖这个接口。而具体的数据访问实现（如JdbcUserRepositoryImpl或JpaUserRepositoryImpl）则实现该接口。这样，如果将来需要更换数据库或ORM框架，只需提供新的接口实现，业务逻辑层代码无需修改。 - 通知服务：一个应用需要发送通知，可能通过邮件、短信或App推送。应用的核心逻辑（高层）不应直接调用
EmailSender或SmsSender。应定义一个NotificationService接口，核心逻辑依赖此接口。然后提供EmailNotificationService、SmsNotificationService等具体实现。 - 插件化系统：主应用程序（高层）定义插件需要遵循的接口（抽象）。各种插件（低层）实现这些接口来提供特定功能。主应用程序通过加载和调用这些插件接口来扩展功能，而无需知道插件的具体实现细节。
- MVC/MVP/MVVM架构模式：在这些UI架构模式中，通常Presenter/ViewModel（高层逻辑）会依赖于View的抽象接口，而不是具体的View实现。View实现这个接口，并将用户操作通知给Presenter/ViewModel。这种方式也体现了DIP。
作用与价值
| 作用维度 | 具体表现 |
|---|---|
| 降低耦合度 | 模块间的依赖关系通过抽象建立，减少了直接依赖，使得系统更加松耦合。 |
| 提高系统灵活性 | 可以轻松替换或修改低层模块的具体实现，而不影响高层模块。 |
| 增强可扩展性 | 新的功能或实现可以通过实现已有的抽象接口来加入系统。 |
| 提高代码可测试性 | 易于对高层模块进行单元测试，可以使用Mock对象替代真实的依赖。 |
| 促进并行开发 | 接口定义后，高层和低层模块可以独立开发和测试。 |
| 使架构更清晰 | 强调面向接口编程，使得系统的层次和模块边界更加清晰。 |
代码示例 (Kotlin)
场景：一个报告生成服务需要从数据源获取数据。
违反DIP的例子：
// 低层模块：具体的数据源实现
class MySqlDatabase_Violates_DIP {
fun queryData(): List<String> {
println("Querying data from MySQL Database...")
return listOf("Data1_MySQL", "Data2_MySQL")
}
}
// 高层模块：报告生成服务直接依赖于具体的MySqlDatabase
class ReportGenerator_Violates_DIP {
private val database = MySqlDatabase_Violates_DIP() // 直接依赖具体实现
fun generateReport(): String {
val data = database.queryData()
return "Report based on: ${data.joinToString()}"
}
}
// 使用
// val reportGenBad = ReportGenerator_Violates_DIP()
// println(reportGenBad.generateReport())
// 如果要换成Oracle数据库，ReportGenerator_Violates_DIP类就需要修改
在这个例子中，ReportGenerator_Violates_DIP（高层模块）直接依赖于MySqlDatabase_Violates_DIP（低层模块的具体实现）。如果将来需要从其他数据源（如Oracle数据库或CSV文件）获取数据，就必须修改ReportGenerator_Violates_DIP类。
遵循DIP的例子：
// 步骤1: 定义抽象接口（数据源接口）
interface DataSource_DIP {
fun fetchData(): List<String>
}
// 步骤2: 低层模块实现这个抽象接口
class MySqlDatabase_DIP : DataSource_DIP {
override fun fetchData(): List<String> {
println("Fetching data from MySQL Database (DIP compliant)...")
return listOf("MySQL_Data1", "MySQL_Data2")
}
}
class OracleDatabase_DIP : DataSource_DIP {
override fun fetchData(): List<String> {
println("Fetching data from Oracle Database (DIP compliant)...")
return listOf("Oracle_DataA", "Oracle_DataB")
}
}
class CsvFileSource_DIP : DataSource_DIP {
override fun fetchData(): List<String> {
println("Fetching data from CSV File (DIP compliant)...")
return listOf("CSV_RecordX", "CSV_RecordY")
}
}
// 步骤3: 高层模块依赖于抽象接口
// 通常通过构造函数注入、Setter注入或接口注入来提供具体实现
class ReportGenerator_DIP(private val dataSource: DataSource_DIP) { // 依赖于抽象
fun generateReport(): String {
val data = dataSource.fetchData() // 调用抽象接口的方法
return "Report (DIP compliant) based on: ${data.joinToString()}"
}
}
// 使用
// val mySqlDataSource = MySqlDatabase_DIP()
// val reportGenMySql = ReportGenerator_DIP(mySqlDataSource)
// println(reportGenMySql.generateReport())
// val oracleDataSource = OracleDatabase_DIP()
// val reportGenOracle = ReportGenerator_DIP(oracleDataSource)
// println(reportGenOracle.generateReport())
// val csvDataSource = CsvFileSource_DIP()
// val reportGenCsv = ReportGenerator_DIP(csvDataSource)
// println(reportGenCsv.generateReport())
// ReportGenerator_DIP类无需任何修改即可适应不同的数据源
在这个遵循DIP的例子中，ReportGenerator_DIP（高层模块）依赖于DataSource_DIP接口（抽象）。具体的数据库实现（如MySqlDatabase_DIP、OracleDatabase_DIP）都实现了这个接口。通过依赖注入（这里是构造函数注入），我们可以向ReportGenerator_DIP提供不同的数据源实现，而ReportGenerator_DIP本身的代码不需要任何修改。
优缺点
| 优点 | 缺点 |
|---|---|
| 显著降低模块间的耦合度。 | 可能增加类的数量和系统复杂度：引入抽象层和依赖注入机制可能会使得类的数量增多，理解系统的调用链可能需要更多步骤。 |
| 提高系统的灵活性、可扩展性和可维护性。 | 需要更周全的设计：定义稳定且合适的抽象接口需要仔细的分析和设计。如果抽象设计不当，反而可能成为系统的瓶颈。 |
| 非常有利于单元测试。 | 对于非常简单或变化极少的系统，可能显得过度设计。 |
| 促进团队并行开发。 |
最佳实践与应用指南
- 每个类都应该有接口或抽象类，或者说，每个类都应该针对接口编程。 （这是一个理想化的说法，实践中对于一些简单的数据对象或工具类可能不需要严格遵循）。
- 类间的依赖关系应该建立在接口或抽象类（抽象）之上，而不是具体类（细节）之上。
- 抽象不应该依赖于细节。 即接口或抽象类的设计不应该过多地考虑其具体实现类的细节。
- 细节应该依赖于抽象。 具体实现类应该实现或继承抽象层定义的接口或方法。
- 使用依赖注入（Dependency Injection, DI）：DI是实现DIP的重要手段。常见的DI方式有构造函数注入、Setter方法注入、接口注入。DI容器（如Spring, Guice, Dagger, Koin）可以自动化依赖对象的创建和注入过程。
- 工厂模式（Factory Pattern）或服务定位器模式（Service Locator Pattern） 也可以用来帮助解耦高层模块对具体实现的依赖，但DI通常被认为是更优的方式。
- 避免在代码中直接使用
new关键字创建具体依赖的实例 （除非是在工厂或DI容器的配置中）。高层模块应该从外部获取其依赖的实例。 - 定义稳定且职责清晰的抽象接口：接口一旦发布，应尽量保持稳定。接口的设计应遵循单一职责原则和接口隔离原则。
依赖倒置原则是构建高质量、松耦合、易于演进的软件系统的核心思想。通过依赖于抽象而非具体实现，我们可以有效地隔离变化，提高系统的整体灵活性和可维护性。
请务必谨记，任何原则的运用都需结合项目实际需求灵活变通，深刻理解原则背后的设计思想远比机械地套用条文更为重要。
添加公众号第一时间了解最新内容。
欢迎入群交流QQ：276097690
