一、简介
SOLID原则是面向对象设计中的重要原则，旨在使软件设计更易于理解、维护和扩展。这些原则由Robert C. Martin提出，并由Michael Feathers用首字母缩略词SOLID表示。SOLID原则包括：
- S - 单一职责原则（Single Responsibility Principle, SRP）
- O - 开放封闭原则（Open/Closed Principle, OCP）
- L - 里氏替换原则（Liskov Substitution Principle, LSP）
- I - 接口隔离原则（Interface Segregation Principle, ISP）
- D - 依赖倒置原则（Dependency Inversion Principle, DIP）
二、SOLID 原则详解
1. S - 单一职责原则
-
核心思想：一个类应该只有一个引起变化的原因。换句话说，一个类应该只负责一项职责。
-
为什么要遵守：如果一个类承担了过多的职责，那么这些职责就会耦合在一起。修改其中一个职责可能会意外地影响到其他职责，使得代码变得脆弱、难以理解和维护。
-
违反 SRP 的例子：
// 这个类承担了太多的责任：员工信息管理、计算工资、生成报表 public class Employee { private String name; private String id; private double salary; // ... 构造函数、getters、setters ... // 职责1：业务逻辑 - 计算奖金 public double calculateBonus() { return this.salary * 0.10; } // 职责2：数据持久化 - 保存到数据库 public void saveToDatabase() { // 数据库连接、SQL执行等代码... System.out.println("员工 " + name + " 已保存到数据库。"); } // 职责3：报表生成 - 生成员工详情报表 public void generateReport() { // 复杂的报表生成逻辑... System.out.println("为员工 " + name + " 生成报表。"); } } -
问题：如果数据库连接方式改变、报表格式需要调整、或者奖金计算逻辑修改，我们都必须修改同一个 Employee 类。这违反了“单一变化原因”的原则。
-
遵循 SRP 的改进：将不同的职责拆分到不同的类中。
// 职责1：纯粹的数据模型 - 只包含员工属性和基础业务逻辑 public class Employee { private String name; private String id; private double salary; // ... 构造函数、getters、setters ... public double calculateBonus() { return this.salary * 0.10; } } // 职责2：专门负责数据持久化 public class EmployeeRepository { public void save(Employee employee) { // 数据库连接、SQL执行等代码... System.out.println("员工 " + employee.getName() + " 已保存到数据库。"); } } // 职责3：专门负责报表生成 public class EmployeeReportGenerator { public void generateReport(Employee employee) { // 复杂的报表生成逻辑... System.out.println("为员工 " + employee.getName() + " 生成报表。"); } } -
好处：
- Employee 类现在只关心员工的核心数据和业务逻辑。
- 如果数据库操作需要改变，只需修改 EmployeeRepository。
- 如果报表逻辑需要改变，只需修改 EmployeeReportGenerator。
- 提高类的内聚性，降低类的复杂度，使代码更易于理解和修改。
2. O - 开闭原则
-
核心思想：软件实体（类、模块、函数等）应该对扩展开放，但对修改关闭。
-
为什么要遵守：当需求发生变化时，我们应该通过添加新的代码来扩展功能，而不是修改已有的、已经测试过的旧代码。这极大地提高了系统的稳定性和可维护性。
-
违反 OCP 的例子：
public class AreaCalculator { public double calculateArea(Object shape) { if (shape instanceof Circle) { Circle circle = (Circle) shape; return Math.PI * circle.getRadius() * circle.getRadius(); } else if (shape instanceof Rectangle) { Rectangle rectangle = (Rectangle) shape; return rectangle.getLength() * rectangle.getWidth(); } // 每增加一种新的图形，我们都需要修改这个方法，添加一个新的if-else分支 throw new IllegalArgumentException("未知图形类型"); } } -
问题：每次添加新的图形（如三角形），我们都必须修改 AreaCalculator 类的 calculateArea 方法，这违反了“对修改关闭”的原则。
-
遵循 OCP 的改进：使用抽象（接口或抽象类）来定义一个稳定的契约，让具体的实现来扩展功能。
// 1. 定义一个抽象的“形状”接口 public interface Shape { double calculateArea(); } // 2. 具体图形实现这个接口 public class Circle implements Shape { private double radius; public Circle(double radius) { this.radius = radius; } @Override public double calculateArea() { return Math.PI * radius * radius; } } public class Rectangle implements Shape { private double length; private double width; public Rectangle(double length, double width) { this.length = length; this.width = width; } @Override public double calculateArea() { return length * width; } } // 3. 面积计算器现在依赖于抽象，而不是具体实现 public class AreaCalculator { public double calculateArea(Shape shape) { // 它不再需要知道具体的图形类型，只需调用calculateArea方法 return shape.calculateArea(); } } -
好处：
- 现在要添加一个 Triangle（三角形），我们只需要创建一个新的类实现 Shape 接口即可，完全不需要修改 AreaCalculator 类。
- AreaCalculator 对扩展是开放的（可以接受任何新的 Shape），同时对修改是关闭的。
- 在不修改现有代码的情况下，通过扩展来添加新功能，从而保持系统的稳定性和减少引入新错误的风险。
3. L - 里氏替换原则
-
核心思想：子类型必须能够替换掉它们的基类型，而不破坏程序的正确性。
-
为什么要遵守：它确保了继承关系的正确使用。如果子类不能完全替代父类，那么继承体系就是不合理的，会在使用多态时导致意外的错误。
-
违反 LSP 的例子：
class Rectangle { protected int width; protected int height; public void setWidth(int width) { this.width = width; } public void setHeight(int height) { this.height = height; } public int getArea() { return width * height; } } // 从数学上讲，正方形“是一个”矩形 class Square extends Rectangle { @Override public void setWidth(int width) { super.setWidth(width); super.setHeight(width); // 违反行为：设置宽的同时也设置了高 } @Override public void setHeight(int height) { super.setWidth(height); // 违反行为：设置高的同时也设置了宽 super.setHeight(height); } } -
问题：现在看下面这个函数，它期望一个 Rectangle 对象：
public void testRectangle(Rectangle r) { // 如果传入的 r 是Square对象 r.setWidth(5); r.setHeight(4); // 这里执行时，会调用Square对象的setHeight方法，会把setWidth也设置成4 assert r.getArea() == 20; // 这里调用getArea方法的结果是16。 }- 这里testRectangle函数中，期望传入的对象r的宽和高可以独立设置。
- 如果你传入一个Square对象，程序的行为就会出错，因为Square继承了Rectangle类，这个函数是可以传入一个Square对象，而在Square对象中改变了setWidth和setHeight的预期行为。所以Square 对象无法替换 Rectangle 对象而不改变程序的行为，违反了 LSP。
-
遵循 LSP 原则的思路：重新设计继承体系，比如让Rectangle和Square都继承自一个更通用的Shape类，而不是让Square继承Rectangle。
4. I - 接口隔离原则
-
核心思想：客户端不应该被强迫依赖于它不使用的接口。将一个庞大的接口拆分成更小、更具体的接口。
-
为什么要遵守：如果一个接口包含太多方法，那么实现它的类就不得不实现所有方法，即使有些方法对它们来说毫无意义（通常只能抛出异常）。这会导致“接口污染”和“胖接口”问题。
-
违反 ISP 的例子：
// 一个“胖”的工作者接口 public interface Worker { void work(); void eat(); void sleep(); } // 机器人工人：它只需要工作，不需要吃饭睡觉 public class RobotWorker implements Worker { @Override public void work() { /* ... 工作 ... */ } @Override public void eat() { throw new UnsupportedOperationException("机器人不需要吃饭！"); } @Override public void sleep() { throw new UnsupportedOperationException("机器人不需要睡觉！"); } } -
问题：RobotWorker 被迫实现了它根本用不到的方法，这违反了接口隔离原则。
-
遵循 ISP 的改进：将大接口拆分成多个特定于客户端的接口。
// 1. 拆分成更精细的接口 public interface Workable { void work(); } public interface Eatable { void eat(); } public interface Sleepable { void sleep(); } // 2. 人类工人可以实现所有需要的接口 public class HumanWorker implements Workable, Eatable, Sleepable { @Override public void work() { /* ... */ } @Override public void eat() { /* ... */ } @Override public void sleep() { /* ... */ } } // 3. 机器人工人只实现它需要的Workable接口 public class RobotWorker implements Workable { @Override public void work() { /* ... */ } } -
好处：
- 客户端（例如使用 Worker 的代码）只需依赖于它们真正关心的接口。
- 没有类会被强迫实现与它无关的方法。
- 系统更加解耦。
5. D - 依赖倒置原则
-
核心思想：
- 高层模块不应该依赖于低层模块。二者都应该依赖于抽象。
- 抽象不应该依赖于细节。细节应该依赖于抽象。
-
为什么要遵守：它通过引入抽象层来解耦高层业务逻辑和低层实现细节。这使得系统更灵活，更容易替换底层组件（例如，从 MySQL 数据库切换到 PostgreSQL，或从文件存储切换到云存储）。
-
违反 DIP 的例子：
// 低层模块：具体的数据库操作 public class MySQLDatabase { public void connect() { /* ... */ } public void saveData(String data) { /* ... */ } } // 高层模块：业务逻辑，直接依赖于低层模块的具体实现 public class DataService { // 紧耦合！DataService 直接依赖于 MySQLDatabase private MySQLDatabase database; public DataService() { this.database = new MySQLDatabase(); // 直接实例化，无法替换 } public void processData(String data) { database.connect(); database.saveData(data); } } -
问题：如果想把数据库从 MySQL 换成 MongoDB，我们必须修改 DataService 类的代码。
-
遵循 DIP 的改进：引入一个抽象层（接口），让高层和低层都依赖于这个抽象。
// 1. 抽象层（接口） public interface Database { void connect(); void saveData(String data); } // 2. 低层模块实现抽象 public class MySQLDatabase implements Database { @Override public void connect() { /* ... MySQL 连接 ... */ } @Override public void saveData(String data) { /* ... */ } } public class MongoDBDatabase implements Database { @Override public void connect() { /* ... MongoDB 连接 ... */ } @Override public void saveData(String data) { /* ... */ } } // 3. 高层模块依赖于抽象，而不是具体实现 public class DataService { // 松耦合！DataService 依赖于 Database 接口 private Database database; // 依赖通过构造器注入（控制反转 IoC 的一种形式） public DataService(Database database) { this.database = database; } public void processData(String data) { database.connect(); database.saveData(data); } } -
好处：
- DataService 不再关心具体使用哪种数据库，它只关心 Database 接口提供的契约。
- 可以轻松地切换数据库实现，而无需修改 DataService 的任何一行代码。
- 极大地提高了代码的可测试性，可以轻松地注入一个 MockDatabase 进行单元测试。
三、总结
| 原则 | 核心思想 | 关键好处 |
|---|---|---|
| 单一职责 | 一个类只做一件事 | 提高可维护性，降低复杂度 |
| 开闭原则 | 对扩展开放，对修改关闭 | 提高可扩展性，减少回归测试 |
| 里氏替换 | 子类可替换父类 | 保证继承关系的正确性 |
| 接口隔离 | 接口要小而专一 | 避免接口污染，提高灵活性 |
| 依赖倒置 | 依赖抽象而非实现 | 降低耦合度，提高可测试性 |
扫一扫
818
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
