做网站要学那些,中国建设银行安徽省分行网站,建网站多少费用,国外做连接器平台网站面向对象设计的五大原则#xff08;SOLID 原则#xff09;是指导我们设计可维护、灵活且易扩展的面向对象系统的核心准则。这些原则帮助开发者避免常见的设计陷阱#xff0c;使代码更具可读性和可维护性。
0.设计原则和设计模式的关系
设计原则#xff08;Design Princip…面向对象设计的五大原则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; // 正方形的宽和高必须相等}
}虽然 Square 是 Rectangle 的子类但由于 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 类它依赖于具体的 BackendDeveloper 和 FrontendDeveloper 类。
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 ListDeveloper developers;public Project(ListDeveloper developers) {this.developers developers;}public void implement() {for (Developer developer : developers) {developer.writeCode();}}
}现在 Project 类依赖于 Developer 接口而不是具体的开发者实现类符合 DIP 原则。 总结
SRP一个类只负责一件事。OCP类应该通过扩展而非修改来应对需求变化。LSP子类可以替代父类不改变程序行为。ISP接口应该小而精避免无关功能。DIP高层模块依赖于抽象而非具体实现。
