欢迎来到尧图网

客户服务 关于我们

您的位置:首页 > 财经 > 产业 > 面向对象设计的五大原则(SOLID 原则)

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

2024/10/24 3:23:01 来源:https://blog.csdn.net/alittlefish1/article/details/142170731  浏览:    关键词:面向对象设计的五大原则(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:高层模块依赖于抽象而非具体实现。

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com