一、单一职责原则（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：组合复用减少继承滥用，间接支持里氏替换。
通过综合应用这些原则，可以构建高内聚、低耦合的系统，提升代码的可维护性和扩展性。