面向对象设计（OOD）中大名鼎鼎的 SOLID原则

前言在软件开发中我们经常听到“高内聚、低耦合”、“可维护性”、“可扩展性”这些词。但到底什么样的代码才算得上“好代码”SOLID 原则就是最经典的答案。很多面试官会问“开放-封闭、单一职责、依赖倒置、里式替换是什么”如果你只答出这四个那你就漏掉了第五个——接口隔离原则I。它们合起来就是SOLID。本文不仅会把这五个原则讲透还会补充DRY、KISS、YAGNI、迪米特法则这四个同样重要的设计原则。每个原则都会配上反例坏代码和正例好代码保证你看完就能用。摘要本文系统梳理了面向对象设计的核心原则。首先详解SOLID五大原则单一职责类只做一件事、开放-封闭扩展开放、修改封闭、里式替换子类可替代父类、接口隔离拆分胖接口和依赖倒置依赖抽象而非具体每个原则均配以反面与正面代码实例对比。随后补充DRY避免重复、KISS保持简单、YAGNI不提前实现和迪米特法则最少知道四项重要补充原则。文章最后提供日常自检清单帮助开发者写出高内聚、低耦合的可维护代码适合面试复习与实战参考。目录一、为什么叫“SOLID”二、SOLID 原则5 个1. S – 单一职责原则Single Responsibility Principle2. O – 开放-封闭原则Open-Closed Principle3. L – 里式替换原则Liskov Substitution Principle4. I – 接口隔离原则Interface Segregation Principle5. D – 依赖倒置原则Dependency Inversion Principle思考为什么叫“依赖倒置”第一步倒置之前父向子看齐—— 违反 DIP第二步依赖倒置之后子向接口看齐—— 符合 DIP第三步为什么叫“倒置”看 Java 中的依赖方向用 Java 的“注解”来总结金句三、SOLID 总结四、软考真题练习一、为什么叫“SOLID”这五个原则合在一起就是为了让你的代码像坚固的固体Solid一样抗震动需求频繁变更时代码不会摇摇欲坠、牵一发动全身。不易碎修改某个模块时不会像多米诺骨牌一样导致其他模块跟着崩溃。二、SOLID 原则5 个1. S – 单一职责原则Single Responsibility Principle一个类只应该有一个发生变化的原因。也就是说一个类只负责一项职责。❌ 反例万能的“员工类”class Employee { void calculateSalary() { /* 计算工资 */ } void saveToDatabase() { /* 连接数据库保存 */ } void printReport() { /* 生成报表 */ } }问题财务改工资算法可能碰坏数据库代码DBA 改表结构又可能影响工资计算。职责揉在一起牵一发而动全身。✅ 正例拆分成独立的类class Employee { // 只负责员工基本信息姓名、工号 } class SalaryCalculator { // 只负责算工资 } class EmployeeRepository { // 只负责数据库操作 } class ReportGenerator { // 只负责生成报表 }好处改工资逻辑只动SalaryCalculator其他类稳如泰山。2. O – 开放-封闭原则Open-Closed Principle对扩展开放对修改封闭。新增功能时尽量通过扩展新增类/方法来实现而不是修改已有代码。❌ 反例满屏if-elsedouble getArea(Object shape) { if (shape instanceof Rectangle) { return width * height; } else if (shape instanceof Circle) { return 3.14 * r * r; } // 新增三角形只能来这里加 else-if —— 违反“对修改封闭” }✅ 正例利用多态不修改老代码interface Shape { double getArea(); } class Rectangle implements Shape { public double getArea() { return width * height; } } class Circle implements Shape { public double getArea() { return 3.14 * r * r; } } // 新增三角形——直接新建类老代码一行不改 class Triangle implements Shape { public double getArea() { return 0.5 * base * height; } }3. L – 里式替换原则Liskov Substitution Principle子类对象必须能够替换父类对象且程序行为不变。子类可以扩展父类的功能但不能改变父类原有的语义。❌ 反例正方形继承长方形经典错误class Rectangle { int width, height; void setWidth(int w) { width w; } void setHeight(int h) { height h; } } class Square extends Rectangle { Override void setWidth(int w) { super.setWidth(w); super.setHeight(w); // 强制宽高相等 } Override void setHeight(int h) { super.setHeight(h); super.setWidth(h); } }问题如果有个方法resize(Rectangle r)先setWidth(5)再setHeight(10)传入Square时结果变成10x10与预期不符——子类无法替换父类。✅ 正例不滥用继承改用接口或组合interface Shape { int getArea(); } class Rectangle implements Shape { int width, height; public int getArea() { return width * height; } } class Square implements Shape { int side; public int getArea() { return side * side; } }原则只有当子类真正能完全替代父类而不影响程序行为时才使用继承。4. I – 接口隔离原则Interface Segregation Principle客户端不应该被迫依赖它用不到的方法。胖接口要拆分成多个专门的接口。❌ 反例臃肿的“全能接口”interface Worker { void work(); void eat(); // 只有人类需要 void sleep(); // 只有人类需要 } class Robot implements Worker { public void work() { /* 工作 */ } public void eat() { /* 被迫空实现 */ } public void sleep() { /* 被迫空实现 */ } }✅ 正例拆分接口interface Workable { void work(); } interface Eatable { void eat(); } interface Sleepable { void sleep(); } class Robot implements Workable { public void work() { /* 工作 */ } } class Human implements Workable, Eatable, Sleepable { public void work() { /* 工作 */ } public void eat() { /* 吃饭 */ } public void sleep() { /* 睡觉 */ } }5. D – 依赖倒置原则Dependency Inversion Principle高层模块不应依赖低层模块两者都应依赖抽象。抽象不应依赖细节细节应依赖抽象。简言之面向接口编程而非面向实现。❌ 反例高层直接依赖具体数据库class UserService { private MySQLDatabase db; // 直接依赖具体类 void saveUser() { db.insert(insert into ...); } }问题想换成 Oracle 或 MongoDB或者做单元测试不想连真库UserService就得大改。✅ 正例依赖抽象接口interface Database { void save(String data); } class MySQLDatabase implements Database { public void save(String data) { /* MySQL 实现 */ } } class MongoDatabase implements Database { public void save(String data) { /* MongoDB 实现 */ } } class UserService { private Database db; // 只依赖接口 void saveUser() { db.save(user data); } }好处切换数据库只改外部注入UserService内部一行都不动。思考为什么叫“依赖倒置”第一步倒置之前父向子看齐—— 违反 DIP在糟糕的设计里Computer类直接new了一个具体的KingstonU盘。此时高层模块Computer被迫依赖低层模块KingstonU盘。// 低层模块具体的金士顿U盘 class KingstonU盘 { public String read() { return 来自金士顿U盘的数据; } } // 高层模块电脑父 class Computer { // 注意电脑直接依赖了具体的U盘类父向子看齐 private KingstonU盘 usb; public Computer() { this.usb new KingstonU盘(); // 写死了具体实现 } public void work() { String data usb.read(); System.out.println(电脑正在处理: data); } } // 测试 public class Main { public static void main(String[] args) { Computer pc new Computer(); pc.work(); } }此时的依赖箭头在 Java 中表现为 import 或直接 newComputer高层----依赖----KingstonU盘低层痛点如果明天想换成三星移动硬盘你必须修改Computer类的构造方法代码。父类代码被迫随着子类变动而变动这就是你所说的“父向子看齐”。第二步依赖倒置之后子向接口看齐—— 符合 DIP我们定义一个 Java 接口作为“统一的契约”。高层和低层都只认这个接口谁也不依赖谁的具体实现。// 1. 定义抽象接口统一的契约 interface StorageDevice { String readData(); } // 2. 低层模块子向接口看齐 class KingstonU盘 implements StorageDevice { Override public String readData() { return 来自金士顿U盘的数据; } } // 另一个低层模块子也向接口看齐 class 三星移动硬盘 implements StorageDevice { Override public String readData() { return 来自三星移动硬盘的数据; } } // 3. 高层模块电脑父也向接口看齐 class Computer { // 电脑不再依赖具体子类而是依赖抽象接口 private StorageDevice device; // 通过构造方法注入依赖注入的标准写法 public Computer(StorageDevice device) { this.device device; } public void work() { String data device.readData(); System.out.println(电脑正在处理: data); } } // 4. 测试 public class Main { public static void main(String[] args) { // 随便换电脑的代码一行都不用改 StorageDevice device1 new KingstonU盘(); Computer pc1 new Computer(device1); pc1.work(); // 轻松切换成移动硬盘 StorageDevice device2 new 三星移动硬盘(); Computer pc2 new Computer(device2); pc2.work(); } }第三步为什么叫“倒置”看 Java 中的依赖方向我们盯着代码中的“箭头指向”即依赖关系倒置前传统Computer类内部new KingstonU盘()并且调用了KingstonU盘特有的方法。依赖方向是Computer高层——KingstonU盘低层。倒置后DIPComputer类内部只有StorageDevice接口的引用。KingstonU盘类实现了StorageDevice接口。依赖方向变成了Computer高层——StorageDevice抽象——KingstonU盘低层看到“倒置”了吗在倒置前低层的KingstonU盘是被高层依赖、需要说白了就是高层要迁就低层认为需要用它在倒置后说白了就是高层定义了一个StorageDevice接口低层的KingstonU盘必须去实现依赖这个接口。这就是所谓的“子U盘向接口看齐”以前是父电脑迁就子现在是子U盘必须符合父规定的标准接口。控制权从子类交到了父类定义的接口手中这就是依赖关系的彻底倒置用 Java 的“注解”来总结金句用 Java 术语翻译过来就是大白话Java 术语映射“父向子看齐”高层模块Computer直接new低层模块具体类编译期强耦合。“子向接口看齐”低层模块U盘类通过implements关键字去实现高层定义的接口。“关系倒置”依赖方向从“高层 → 低层”变为“高层 → 接口 ← 低层”。低层不再被高层直接引用而是主动实现接口来适配高层。这种写法在 Java 生态中极其常见比如List接口搭配ArrayList/LinkedList或者 Spring 框架中Autowired注入接口而非实现类都是依赖倒置原则的经典实践。你已经抓住了它的灵魂三、SOLID 总结缩写中文名称一句话核心S单一职责一个类只干一件事O开放-封闭扩展开放修改封闭L里式替换子类必须能替换父类I接口隔离接口要专一不要臃肿D依赖倒置依赖接口不依赖具体实现四、软考真题练习以上就是本篇文章的全部内容喜欢的话可以留个免费的关注呦~~~