当前位置: 首页 > news >正文

面向对象设计的五大原则(SOLID 原则)

面向对象设计的五大原则(SOLID 原则)是指导我们设计可维护、灵活且易扩展的面向对象系统的核心准则。这些原则帮助开发者避免常见的设计陷阱,使代码更具可读性和可维护性。

0.设计原则和设计模式的关系

设计原则(Design Principles)指的是抽象性比较高、编程都应该遵守的原则,对应的设计模式(Design Pattens)是解决具体场景下特定问题的套路,这里要对两个概念进行区分。换句话说,设计模式要遵循设计原则。

1. 单一职责原则(SRP - Single Responsibility Principle)

定义:一个类应该只有一个引起它变化的原因,即一个类只负责一个功能或职责。

示例
假设我们有一个类负责处理用户信息,同时负责生成用户报告。这样当用户信息或报告格式发生变化时,都会影响到同一个类,违背了 SRP。

class User {String name;String email;public void saveUser() {// 保存用户信息到数据库}public void generateUserReport() {// 生成用户报告}
}

改进:将用户管理和报告生成拆分为两个类。

class User {String name;String email;public void saveUser() {// 保存用户信息到数据库}
}class UserReportGenerator {public void generateUserReport(User user) {// 生成用户报告}
}

这样,如果用户管理和报告生成的逻辑变更,它们只会影响各自相关的类。


2. 开放封闭原则(OCP - Open/Closed Principle)

定义:软件实体(类、模块、函数等)应该对扩展开放,对修改封闭。即当系统需求变化时,应该通过扩展类的行为,而不是修改已有的类来实现。

示例
假设我们有一个用于处理图形的类,包含绘制不同图形的逻辑。

class GraphicEditor {public void drawShape(Shape s) {if (s instanceof Circle) {drawCircle((Circle) s);} else if (s instanceof Square) {drawSquare((Square) s);}}private void drawCircle(Circle c) {// 绘制圆形}private void drawSquare(Square s) {// 绘制方形}
}

如果需要支持绘制新形状,例如三角形,就需要修改 drawShape 方法,违反了 OCP。

改进:通过抽象类或接口实现扩展性。

abstract class Shape {public abstract void draw();
}class Circle extends Shape {@Overridepublic void draw() {// 绘制圆形}
}class Square extends Shape {@Overridepublic void draw() {// 绘制方形}
}class GraphicEditor {public void drawShape(Shape s) {s.draw();}
}

现在如果要支持新形状,只需要添加新类,而不需要修改已有代码。


3. 里氏替换原则(LSP - Liskov Substitution Principle)

定义:子类对象必须能够替换其父类对象,程序的行为应该保持不变。即子类应当完整实现父类的行为,而不应违背父类的契约。

示例
假设我们有一个 Rectangle(矩形)类,后来引入了 Square(正方形)作为它的子类。

class Rectangle {protected int width;protected int height;public void setWidth(int width) {this.width = width;}public void setHeight(int height) {this.height = height;}
}class Square extends Rectangle {@Overridepublic void setWidth(int width) {this.width = width;this.height = width; // 正方形的宽和高必须相等}@Overridepublic void setHeight(int height) {this.height = height;this.width = height; // 正方形的宽和高必须相等}
}

虽然 SquareRectangle 的子类,但由于 Square 违反了矩形的宽高独立性,它无法正确替换 Rectangle

改进:避免继承错误的层次关系。

class Rectangle {protected int width;protected int height;public void setWidth(int width) {this.width = width;}public void setHeight(int height) {this.height = height;}
}class Square {private int sideLength;public void setSideLength(int sideLength) {this.sideLength = sideLength;}
}

正方形和矩形应该是独立的类,不应通过继承关系来实现。


4. 接口隔离原则(ISP - Interface Segregation Principle)

定义:一个类不应该依赖于它不需要的接口。即接口应该尽量小而精简,不要强迫实现类去实现无关的方法。

示例
假设有一个大型接口 Worker,它定义了很多不同类型工人的职责。

interface Worker {void work();void eat();
}class Developer implements Worker {@Overridepublic void work() {// 开发代码}@Overridepublic void eat() {// 吃午餐}
}class Robot implements Worker {@Overridepublic void work() {// 执行任务}@Overridepublic void eat() {// 机器人不需要吃饭}
}

Robot 需要实现 eat 方法,但实际上并不需要这个功能,违反了 ISP。

改进:将接口分割成多个小接口。

interface Workable {void work();
}interface Eatable {void eat();
}class Developer implements Workable, Eatable {@Overridepublic void work() {// 开发代码}@Overridepublic void eat() {// 吃午餐}
}class Robot implements Workable {@Overridepublic void work() {// 执行任务}
}

现在 Robot 只需实现 Workable 接口,不再被迫实现与自己无关的功能。


5. 依赖倒置原则(DIP - Dependency Inversion Principle)

定义:高层模块不应该依赖于低层模块,二者都应该依赖于抽象。换句话说,依赖于抽象,而不是具体实现。

示例
假设我们有一个 Developer 类,它依赖于具体的 BackendDeveloperFrontendDeveloper 类。

class BackendDeveloper {public void writeJava() {// 编写 Java 代码}
}class FrontendDeveloper {public void writeJavaScript() {// 编写 JavaScript 代码}
}class Project {private BackendDeveloper backendDeveloper = new BackendDeveloper();private FrontendDeveloper frontendDeveloper = new FrontendDeveloper();public void implement() {backendDeveloper.writeJava();frontendDeveloper.writeJavaScript();}
}

Project 类直接依赖于具体的开发者实现类,违反了 DIP。

改进:通过抽象接口进行依赖倒置。

interface Developer {void writeCode();
}class BackendDeveloper implements Developer {@Overridepublic void writeCode() {// 编写 Java 代码}
}class FrontendDeveloper implements Developer {@Overridepublic void writeCode() {// 编写 JavaScript 代码}
}class Project {private List<Developer> developers;public Project(List<Developer> developers) {this.developers = developers;}public void implement() {for (Developer developer : developers) {developer.writeCode();}}
}

现在 Project 类依赖于 Developer 接口,而不是具体的开发者实现类,符合 DIP 原则。


总结

  • SRP:一个类只负责一件事。
  • OCP:类应该通过扩展而非修改来应对需求变化。
  • LSP:子类可以替代父类,不改变程序行为。
  • ISP:接口应该小而精,避免无关功能。
  • DIP:高层模块依赖于抽象而非具体实现。
http://www.lryc.cn/news/440008.html

相关文章:

  • Python和MATLAB及C++信噪比导图(算法模型)
  • App及web反编译方案
  • 学成在线练习(HTML+CSS)
  • istio中使用serviceentry结合egressgateway实现多版本路由
  • Java项目——苍穹外卖(二)
  • 【Python日志功能】三.日志记录方法与多模块日志
  • 在pycharm终端中运行pip命令安装模块时,出现了“你要如何打开这个文件”弹出窗口,是什么状况?
  • Axure多人协调的方式
  • 【深度学习】【OnnxRuntime】【Python】模型转化、环境搭建以及模型部署的详细教程
  • React学习笔记(1.0)
  • Axure RP实战:打造高效图形旋转验证码
  • 101012分页属性
  • 从0-1 用AI做一个赚钱的小红书账号(不是广告不是广告)
  • 【Kubernetes】常见面试题汇总(十七)
  • Vue 3 中动态赋值 ref 的应用
  • Spring Boot-应用启动问题
  • 深入解析:如何通过网络命名空间跟踪单个进程的网络活动(C/C++代码实现)
  • C++ 科目二 [const_cast]
  • 【电脑组装】✈️从配置拼装到安装系统组装自己的台式电脑
  • Hadoop生态圈拓展内容(一)
  • 使用随机森林模型在digits数据集上执行分类任务
  • 后端开发刷题 | 打家劫舍
  • 欧美游戏市场的差异
  • DeDeCMS靶场漏洞复现
  • Transformer模型详细步骤
  • LC并联电路在正弦稳态下的传递函数推导(LC并联谐振选频电路)
  • 【前后端】大文件切片上传
  • 图像处理 -- ISP功能之局部对比度增强 LCE
  • C++速通LeetCode简单第5题-回文链表
  • 【Java 优选算法】双指针(下)