一、单一职责原则(Single Responsibility Principle, SRP)
定义
一个类应该有且仅有一个引起它变化的原因(即一个类只负责一个职责)。
核心思想
-
高内聚:类的功能高度集中
-
低耦合:减少不同职责之间的相互影响
-
提升可维护性:修改一个功能不会波及其他功能
违反SRP的示例
// 一个类同时处理订单逻辑和数据库操作 class OrderService { // 职责1:计算订单总价 public double calculateTotal(Order order) { // 计算逻辑... } // 职责2:保存到数据库 public void saveToDatabase(Order order) { // 数据库操作... } // 职责3:发送邮件通知 public void sendEmail(Order order) { // 邮件发送逻辑... } }
问题:
订单计算、数据库存储、邮件通知这三个职责耦合在一起,任一需求变更都需要修改该类。
符合SRP的改进
// 拆分三个独立类 class OrderCalculator { public double calculateTotal(Order order) { /*...*/ } } class OrderRepository { public void saveToDatabase(Order order) { /*...*/ } } class EmailService { public void sendEmail(Order order) { /*...*/ } } // 通过组合方式使用 class OrderService { private OrderCalculator calculator; private OrderRepository repository; private EmailService emailService; public void processOrder(Order order) { double total = calculator.calculateTotal(order); repository.saveToDatabase(order); emailService.sendEmail(order); } }
优势:
-
每个类职责明确
-
修改邮件发送逻辑不会影响订单计算
-
更易复用(例如EmailService可用于其他模块)
二、开闭原则(Open/Closed Principle, OCP)
定义
软件实体(类、模块、函数等)应该对扩展开放,对修改关闭。
核心思想
-
通过抽象和继承/组合实现扩展
-
不修改已有代码即可添加新功能
-
减少回归测试风险
违反OCP的示例
class ShapeDrawer { public void draw(String shapeType) { if (shapeType.equals("circle")) { drawCircle(); } else if (shapeType.equals("square")) { drawSquare(); } // 添加新图形需要修改此方法 } private void drawCircle() { /*...*/ } private void drawSquare() { /*...*/ } }
问题:
每次新增图形类型都需要修改draw()
方法,违反开闭原则。
符合OCP的改进
// 抽象接口 interface Shape { void draw(); } // 具体实现类 class Circle implements Shape { @Override public void draw() { /*...*/ } } class Square implements Shape { @Override public void draw() { /*...*/ } } // 扩展时不修改原有代码 class Triangle implements Shape { @Override public void draw() { /*...*/ } } class ShapeDrawer { public void draw(Shape shape) { shape.draw(); // 通过多态调用 } }
优势:
-
新增图形类型只需添加新类
-
无需修改
ShapeDrawer
类 -
客户端代码保持稳定
三、装饰者模式中的双原则体现
// 1. Component 接口
interface Beverage {
double cost();
}// 2. ConcreteComponent
class BlackCoffee implements Beverage {
@Override
public double cost() {
return 2.0; // 基础咖啡价格
}
}// 3. Decorator 抽象类
abstract class BeverageDecorator implements Beverage {
protected Beverage beverage;
public BeverageDecorator(Beverage beverage) {
this.beverage = beverage;
}
}// 4. ConcreteDecorator 具体装饰者
class Sugar extends BeverageDecorator {
public Sugar(Beverage beverage) {
super(beverage);
}@Override
public double cost() {
return beverage.cost() + 0.5; // 加糖价格
}
}class Milk extends BeverageDecorator {
public Milk(Beverage beverage) {
super(beverage);
}@Override
public double cost() {
return beverage.cost() + 1.0; // 加奶价格
}
}
回顾之前的咖啡加料示例:
1. SRP体现
-
Sugar
装饰器只负责加糖价格计算 -
Milk
装饰器只负责加奶价格计算 -
BlackCoffee
只提供基础咖啡功能
2. OCP体现
-
添加新配料(如
Chocolate
)时:class Chocolate extends BeverageDecorator { public Chocolate(Beverage beverage) { super(beverage); } @Override public double cost() { return beverage.cost() + 1.5; } }
-
无需修改已有的
Beverage
、BlackCoffee
或其他装饰器类
四、实际应用对比
案例:支付系统设计
违反OCP的写法
class PaymentProcessor { public void process(String paymentType) { if (paymentType.equals("alipay")) { // 处理支付宝 } else if (paymentType.equals("wechat")) { // 处理微信支付 } // 新增支付方式需要修改此处 } }
符合OCP的写法
interface Payment { void process(); } class Alipay implements Payment { @Override public void process() { /*...*/ } } class WechatPay implements Payment { @Override public void process() { /*...*/ } } // 新增支付方式 class BitcoinPayment implements Payment { @Override public void process() { /*...*/ } } class PaymentProcessor { public void process(Payment payment) { payment.process(); } }
五、原则关系图
SRP ▲ │ 通过拆分单一职责 │ ▼ OCP ◄──┐ │ 通过抽象扩展 ▼ 系统稳定性
关键点:
-
SRP是OCP的基础:只有每个类职责单一,才能保证扩展时不会引发意外副作用
-
OCP是SRP的目标:通过合理职责划分实现可扩展性
掌握这两个原则,可以显著提升代码的可维护性和可扩展性。实际开发中建议结合设计模式(如装饰者、策略、工厂模式)来实践这些原则。
其他原则补充
1. 里氏替换原则(Liskov Substitution Principle, LSP)
定义:子类必须能够替换父类,且不影响程序的正确性。
核心:继承关系中子类不应破坏父类的行为逻辑。
示例:
-
违反LSP的场景:若父类
Bird
有fly()
方法,但子类Penguin
(企鹅)不会飞,强制继承会导致方法异常。 -
符合LSP的改进:拆分接口,区分会飞和不会飞的鸟类。
interface Bird { void eat(); } interface FlyingBird extends Bird { void fly(); } class Penguin implements Bird { /* 无需实现fly() */ } class Swallow implements FlyingBird { /* 实现fly() */ }
2. 接口隔离原则(Interface Segregation Principle, ISP)
定义:客户端不应依赖它不需要的接口,避免“胖接口”。
核心:通过拆分接口减少冗余依赖。
示例:
-
违反ISP的场景:
Printer
接口包含print()
和scan()
方法,但OnlyPrintPrinter
类不需要扫描功能。 -
符合ISP的改进:拆分为
Printable
和Scannable
接口。
interface Printable { void print(); } interface Scannable { void scan(); } class AllInOnePrinter implements Printable, Scannable { /* 实现全部 */ } class OnlyPrintPrinter implements Printable { /* 仅打印 */ }
3. 依赖倒置原则(Dependency Inversion Principle, DIP)
定义:高层模块不依赖低层模块,二者都依赖抽象;抽象不依赖细节,细节依赖抽象。
核心:通过抽象解耦模块间的直接依赖。
示例:
-
违反DIP的场景:
OrderService
直接依赖MySQLDatabase
,难以切换数据库。 -
符合DIP的改进:引入
Database
接口,依赖抽象。
interface Database { void connect(); } class MySQLDatabase implements Database { /* 实现MySQL连接 */ } class OrderService { private Database db; public OrderService(Database db) { this.db = db; } }
4. 迪米特法则(Law of Demeter, LoD)/ 最少知识原则
定义:对象应减少对其他对象的直接依赖,仅与“直接朋友”交互。
核心:通过中介者降低耦合。
示例:
-
违反LoD的场景:客户类
Customer
直接调用厨房类Kitchen
和收银类Cashier
。 -
符合LoD的改进:引入
OrderManager
中介类。
class OrderManager { private Kitchen kitchen; private Cashier cashier; public void processOrder() { /* 协调厨房和收银 */ } } class Customer { public void placeOrder(OrderManager manager) { manager.processOrder(); } }
5. 组合复用原则(Composite Reuse Principle, CRP)
定义:优先使用组合(has-a)而非继承(is-a)实现复用。
核心:避免继承带来的类爆炸问题。
示例:
-
继承的缺点:汽车类通过继承处理变速箱类型(自动/手动)会导致类爆炸。
-
组合的改进:将变速箱抽象为独立组件,通过组合集成。
interface Transmission { void shift(); } class AutomaticTransmission implements Transmission { /* 自动换挡 */ } class Car { private Transmission transmission; public Car(Transmission t) { this.transmission = t; } }
总结与原则关联性
这些原则相互关联,例如:
-
DIP 与 OCP:依赖倒置是实现开闭原则的基础(通过抽象扩展功能)。
-
ISP 与 SRP:接口隔离是单一职责在接口设计中的体现。
-
CRP 与 LSP:组合复用减少继承滥用,间接支持里氏替换。
通过综合应用这些原则,可以构建高内聚、低耦合的系统,提升代码的可维护性和扩展性。