在软件开发的生命周期中，代码重构是确保系统长期健康的关键环节。随着业务需求的不断变化，最初的代码设计往往会变得臃肿、难以理解和维护。设计模式作为前人总结的最佳实践，为我们提供了优雅的解决方案。本文将深入探讨如何在重构过程中巧妙融合设计模式，从而显著提升软件的质量与可维护性。
一、理解重构与设计模式的关系
1.1 重构的本质与挑战
重构是在不改变代码外在行为的前提下，改善其内部结构的过程。然而，简单的重构（如重命名变量）往往不足以解决深层次的架构问题。当面对复杂的条件逻辑、紧耦合的组件或重复的代码结构时，我们需要更强大的工具——设计模式。
1.2 设计模式的价值
设计模式不仅仅是代码模板，更是解决特定场景下常见问题的思维框架。在重构中引入设计模式，可以：
降低耦合度
：通过抽象和接口隔离组件依赖
提高内聚性
：将相关职责集中到单一模块
增强扩展性
：遵循开闭原则，便于未来功能扩展
提升可读性
：使用公认的模式名称使代码意图更清晰
二、识别适合引入设计模式的代码坏味道
在重构前，我们需要识别哪些代码问题可以通过设计模式解决：
2.1 大类与长方法
当一个类承担过多职责或方法过长时，可考虑：
策略模式
：分离算法实现
状态模式
：管理对象状态转换
命令模式
：封装请求为对象
2.2 重复的条件分支
多处出现相同的
if-else
或
switch-case
结构时：
状态模式
：将每个分支封装为独立状态类
策略模式
：将不同算法封装为策略
表驱动法
：使用映射表替代条件判断
2.3 紧耦合的依赖关系
当类之间直接依赖具体实现，难以单独测试或替换时：
工厂模式
：隔离对象创建逻辑
依赖注入
：通过接口而非具体类进行依赖
适配器模式
：转换接口以兼容不同系统
2.4 难以扩展的创建逻辑
当对象创建过程复杂且变化频繁时：
工厂方法模式
：定义创建接口，让子类决定实例化
抽象工厂模式
：创建相关对象的家族
建造者模式
：分步构建复杂对象
三、实战案例：从混乱到优雅的重构之旅
3.1 案例背景：电商订单处理系统
假设我们有一个处理订单的系统，原始代码如下：
// 重构前的原始代码
public class OrderProcessor {
public void processOrder(Order order) {
// 验证订单
if (order == null || order.getItems().isEmpty()) {
throw new IllegalArgumentException(“Invalid order”);
}
// 计算价格
double total = 0;
for (Item item : order.getItems()) {
total += item.getPrice() * item.getQuantity();
}
// 应用折扣
if (“VIP”.equals(order.getCustomerType())) {
total *= 0.8; // VIP 8折
} else if (“NEW”.equals(order.getCustomerType())) {
total *= 0.95; // 新用户95折
} else {
// 普通用户无折扣
}
// 支付处理
if (“CREDIT”.equals(order.getPaymentMethod())) {
// 调用信用卡支付接口
System.out.println(“Processing credit card payment: ” + total);
} else if (“PAYPAL”.equals(order.getPaymentMethod())) {
// 调用PayPal支付接口
System.out.println(“Processing PayPal payment: ” + total);
} else if (“BITCOIN”.equals(order.getPaymentMethod())) {
// 调用比特币支付接口
System.out.println(“Processing Bitcoin payment: ” + total);
}
// 发送通知
if (“EMAIL”.equals(order.getNotificationMethod())) {
// 发送邮件
System.out.println(“Sending email notification”);
} else if (“SMS”.equals(order.getNotificationMethod())) {
// 发送短信
System1.out.println(“Sending SMS notification”);
}
// 记录日志
System.out.println(“Order processed: ” + order.getId());
}
}
这段代码存在明显问题：违反单一职责原则、大量条件分支、难以测试和扩展。
3.2 重构策略：引入多种设计模式
步骤1：使用策略模式处理折扣逻辑
首先，我们分离折扣计算逻辑：
// 折扣策略接口
public interface DiscountStrategy {
double applyDiscount(double originalPrice);
}
// VIP折扣策略
public class VipDiscountStrategy implements DiscountStrategy {
@Override
public double applyDiscount(double originalPrice) {
return originalPrice * 0.8;
}
}
// 新用户折扣策略
public class NewCustomerDiscountStrategy implements DiscountStrategy {
@Override
public double applyDiscount(double originalPrice) {
return originalPrice * 0.95;
}
}
// 无折扣策略
public class NoDiscountStrategy implements DiscountStrategy {
@Override
public double applyDiscount(double originalPrice) {
return originalPrice;
}
}
// 折扣策略工厂
public class DiscountStrategyFactory {
public static DiscountStrategy getStrategy(String customerType) {
switch (customerType) {
case “VIP”:
return new VipDiscountStrategy();
case “NEW”:
return new NewCustomerDiscountStrategy();
default:
return new NoDiscountStrategy();
}
}
}
步骤2：使用策略模式处理支付逻辑
同样，支付方式也可以抽象为策略：
// 支付策略接口
public interface PaymentStrategy {
void pay(double amount);
}
// 信用卡支付
public class CreditCardPayment implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println(“Processing credit card payment: $” + amount);
}
}
// PayPal支付
public class PayPalPayment implements PaymentStrategy {
@Override
public void pay(double amount) {
System.out.println(“Processing PayPal payment: $” + amount);
}
}
// 支付策略工厂
public class PaymentStrategyFactory {
public static PaymentStrategy getStrategy(String paymentMethod) {
switch (paymentMethod) {
case “CREDIT”:
return new CreditCardPayment();
case “PAYPAL”:
return new PayPalPayment();
case “BITCOIN”:
return new BitcoinPayment();
default:
throw new IllegalArgumentException(“Unknown payment method”);
}
}
}
步骤3：使用命令模式封装通知逻辑
将通知操作封装为命令对象：
// 命令接口
public interface NotificationCommand {
void execute();
}
// 邮件通知命令
public class EmailNotificationCommand implements NotificationCommand {
private final Order order;
public EmailNotificationCommand(Order order) {
this.order = order;
}
@Override
public void execute() {
System.out.println(“Sending email notification for order: ” + order.getId());
}
}
// 短信通知命令
public class SmsNotificationCommand implements NotificationCommand {
private final Order order;
public SmsNotificationCommand(Order order) {
this.order = order;
}
@Override
public void execute() {
System.out.println(“Sending SMS notification for order: ” + order.getId());
}
}
// 命令工厂
public class NotificationCommandFactory {
public static NotificationCommand createCommand(String method, Order order) {
switch (method) {
case “EMAIL”:
return new EmailNotificationCommand(order);
case “SMS”:
return new SmsNotificationCommand(order);
default:
throw new IllegalArgumentException(“Unknown notification method”);
}
}
}
步骤4：使用模板方法模式重构主流程
现在，我们可以使用模板方法模式定义订单处理的主流程：
// 订单处理器模板
public abstract class AbstractOrderProcessor {
// 模板方法 – 定义处理流程
public final void processOrder(Order order) {
validateOrder(order);
double total = calculateTotal(order);
total = applyDiscount(order, total);
processPayment(order, total);
sendNotification(order);
logOrder(order);
}
// 具体步骤由子类实现或提供默认实现
protected void validateOrder(Order order) {
if (order == null || order.getItems().isEmpty()) {
throw new IllegalArgumentException(“Invalid order”);
}
}
protected double calculateTotal(Order order) {
return order.getItems().stream()
.mapToDouble(item -> item.getPrice() * item.getQuantity())
.sum();
}
protected abstract double applyDiscount(Order order, double total);
protected abstract void processPayment(Order order, double total);
protected abstract void sendNotification(Order order);
protected void logOrder(Order order) {
System.out.println(“Order processed: ” + order.getId());
}
}
// 具体订单处理器
public class StandardOrderProcessor extends AbstractOrderProcessor {
@Override
protected double applyDiscount(Order order, double total) {
DiscountStrategy strategy = DiscountStrategyFactory.getStrategy(order.getCustomerType());
return strategy.applyDiscount(total);
}
@Override
protected void processPayment(Order order, double total) {
PaymentStrategy strategy = PaymentStrategyFactory.getStrategy(order.getPaymentMethod());
strategy.pay(total);
}
@Override
protected void sendNotification(Order order) {
NotificationCommand command = NotificationCommandFactory.createCommand(
order.getNotificationMethod(), order);
command.execute();
}
}
3.3 重构后的优势分析
通过上述重构，我们实现了：
单一职责
：每个类只负责一个方面的逻辑
开闭原则
：新增折扣类型只需添加新的策略类，无需修改现有代码
可测试性
：每个策略类都可以独立测试
可读性
：主流程清晰，意图明确
可维护性
：修改某一方面逻辑不会影响其他部分
四、常见设计模式在重构中的应用场景
4.1 观察者模式：解耦事件通知
当多个对象需要监听某个对象状态变化时：
// 重构前
public class Order {
private List
public void addNotification(Notification notification) {
notifications.add(notification);
}
public void updateStatus(String status) {
this.status = status;
// 直接遍历通知 – 紧耦合
for (Notification n : notifications) {
n.send();
}
}
}
// 重构后：使用观察者模式
public class OrderSubject {
private List
private String status;
public void attach(OrderObserver observer) {
observers.add(observer);
}
public void detach(OrderObserver observer) {
observers.remove(observer);
}
public void setStatus(String status) {
this.status = status;
notifyObservers();
}
private void notifyObservers() {
for (OrderObserver observer : observers) {
observer.update(this.status);
}
}
}
public interface OrderObserver {
void update(String status);
}
public class EmailObserver implements OrderObserver {
@Override
public void update(String status) {
System.out.println(“Email: Order status changed to ” + status);
}
}
4.2 装饰器模式：动态添加职责
当需要在不修改原有类的情况下扩展功能时：
// 重构前：继承导致类爆炸
public class BasicLogger {
public void log(String message) {
System.out.println(“[BASIC] ” + message);
}
}
public class TimestampLogger extends BasicLogger {
@Override
public void log(String message) {
System.out.println(“[TIMESTAMP] ” + new Date() + ” ” + message);
}
}
// 重构后：装饰器模式
public interface Logger {
void log(String message);
}
public class BasicLogger implements Logger {
@Override
public void log(String message) {
System.out.println(“[BASIC] ” + message);
}
}
public abstract class LoggerDecorator implements Logger {
protected Logger wrappedLogger;
public LoggerDecorator(Logger logger) {
this.wrappedLogger = logger;
}
}
public class TimestampLoggerDecorator extends LoggerDecorator {
public TimestampLoggerDecorator(Logger logger) {
super(logger);
}
@Override
public void log(String message) {
wrappedLogger.log(new Date() + ” ” + message);
}
}
public class SecurityLoggerDecorator extends LoggerDecorator {
public SecurityLoggerDecorator(Logger logger) {
super(logger);
}
@Override
public void log(String message) {
wrappedLogger.log(“[SECURE] ” + message);
}
}
// 使用
Logger logger = new BasicLogger();
logger = new TimestampLoggerDecorator(logger);
logger = new SecurityLoggerDecorator(logger);
logger.log(“User logged in”); // 输出: [SECURE] [TIMESTAMP] … User logged in
4.3 适配器模式：集成遗留系统
当需要将新系统与旧接口集成时：
// 旧系统接口
public interface LegacyPaymentService {
void makePayment(double amount, String currency);
}
// 新系统期望的接口
public interface ModernPaymentGateway {
void processPayment(PaymentRequest request);
}
// 适配器
public class PaymentAdapter implements ModernPaymentGateway {
private final LegacyPaymentService legacyService;
public PaymentAdapter(LegacyPaymentService legacyService) {
this.legacyService = legacyService;
}
@Override
public void processPayment(PaymentRequest request) {
// 转换接口
legacyService.makePayment(request.getAmount(), request.getCurrency());
}
}
五、重构过程中的最佳实践
5.1 小步快跑，持续验证
每次只重构一小部分代码，然后运行测试确保功能正常。避免一次性大规模重构导致难以定位问题。
5.2 保持测试覆盖率
在重构前确保有足够的单元测试覆盖核心逻辑。测试是重构的安全网。
5.3 遵循SOLID原则
单一职责
：每个类只做一件事
开闭原则
：对扩展开放，对修改关闭
里氏替换
：子类必须能替换父类
接口隔离
：客户端不应依赖不需要的接口
依赖倒置
：依赖抽象而非具体实现
5.4 使用工具辅助
IDE重构工具
：安全地重命名、提取方法/类
静态分析工具
：检测代码坏味道
代码覆盖率工具
：确保测试充分
5.5 文档与沟通
重构后及时更新文档，并向团队成员说明变更原因和好处。
六、总结
设计模式不是银弹，不能为了使用模式而使用模式。在重构中引入设计模式的关键在于：
识别问题
：准确判断代码坏味道的本质
匹配模式
：选择最适合当前场景的模式
渐进实施
：小步重构，持续集成
验证效果
：通过测试和指标确认改进
通过巧妙融合设计模式，我们不仅能解决当前的技术债务，更能构建一个灵活、健壮、易于维护的软件系统，为未来的业务发展奠定坚实基础。记住，重构和设计模式是相辅相成的工具，它们共同服务于软件工程的终极目标：交付高质量、可持续的软件产品。