代码重构技巧与设计模式在项目中的综合应用实践-源码库

代码重构技巧与设计模式在项目中的综合应用实践

作为一名在软件开发领域摸爬滚打多年的程序员，我深知代码重构和设计模式的重要性。今天我想和大家分享一些在实际项目中综合运用重构技巧和设计模式的实战经验。这些经验都是我在真实项目中踩过坑、吃过亏后总结出来的，希望能帮助大家在提升代码质量的道路上少走弯路。

一、识别重构时机：什么时候该动手

记得我刚接手一个电商项目时，发现订单处理模块的代码已经变得难以维护。每次新增支付方式或优惠策略，都需要修改大量代码，测试工作量巨大。这就是典型的重构信号：

// 重构前的代码示例
public class OrderService {
    public void processOrder(Order order) {
        // 计算价格
        double price = order.getPrice();
        if (order.getUserType().equals("VIP")) {
            price = price * 0.9;
        }
        if (order.getPromotionType().equals("DISCOUNT")) {
            price = price * 0.8;
        }
        // 支付处理
        if (order.getPayType().equals("ALIPAY")) {
            // 支付宝支付逻辑
        } else if (order.getPayType().equals("WECHAT")) {
            // 微信支付逻辑
        }
        // ... 更多if-else
    }
}

这段代码的问题很明显：职责不单一，扩展困难。当我需要新增一个支付方式时，必须修改OrderService类，这违反了开闭原则。

二、策略模式+工厂模式：优雅处理多种业务场景

针对上面的问题，我采用了策略模式结合工厂模式进行重构：

// 定义策略接口
public interface DiscountStrategy {
    double calculateDiscount(double price);
}

public interface PaymentStrategy {
    boolean pay(double amount);
}

// 具体策略实现
public class VIPDiscountStrategy implements DiscountStrategy {
    @Override
    public double calculateDiscount(double price) {
        return price * 0.9;
    }
}

public class AlipayPaymentStrategy implements PaymentStrategy {
    @Override
    public boolean pay(double amount) {
        // 支付宝支付实现
        return true;
    }
}

// 策略工厂
public class StrategyFactory {
    public static DiscountStrategy getDiscountStrategy(String userType) {
        switch (userType) {
            case "VIP": return new VIPDiscountStrategy();
            case "NORMAL": return new NormalDiscountStrategy();
            default: throw new IllegalArgumentException("不支持的折扣类型");
        }
    }
    
    public static PaymentStrategy getPaymentStrategy(String payType) {
        // 类似实现
    }
}

重构后的OrderService变得简洁明了：

public class OrderService {
    public void processOrder(Order order) {
        // 获取折扣策略
        DiscountStrategy discountStrategy = 
            StrategyFactory.getDiscountStrategy(order.getUserType());
        double finalPrice = discountStrategy.calculateDiscount(order.getPrice());
        
        // 获取支付策略
        PaymentStrategy paymentStrategy = 
            StrategyFactory.getPaymentStrategy(order.getPayType());
        paymentStrategy.pay(finalPrice);
    }
}

三、观察者模式：解耦事件处理

在另一个物流管理项目中，我遇到了订单状态变化时需要通知多个系统的问题。最初的做法是在每个状态变更的地方硬编码通知逻辑：

// 重构前
public class Order {
    public void setStatus(OrderStatus status) {
        this.status = status;
        // 通知库存系统
        inventoryService.updateInventory(this);
        // 通知财务系统
        financeService.recordTransaction(this);
        // 通知客服系统
        customerService.notifyCustomer(this);
        // 每新增一个系统就要修改这里
    }
}

使用观察者模式重构后：

// 观察者接口
public interface OrderObserver {
    void onOrderStatusChanged(Order order);
}

// 主题接口
public interface OrderSubject {
    void registerObserver(OrderObserver observer);
    void removeObserver(OrderObserver observer);
    void notifyObservers();
}

// 具体实现
public class Order implements OrderSubject {
    private List observers = new ArrayList<>();
    private OrderStatus status;
    
    @Override
    public void registerObserver(OrderObserver observer) {
        observers.add(observer);
    }
    
    @Override
    public void notifyObservers() {
        for (OrderObserver observer : observers) {
            observer.onOrderStatusChanged(this);
        }
    }
    
    public void setStatus(OrderStatus status) {
        this.status = status;
        notifyObservers(); // 状态变更时通知所有观察者
    }
}

四、重构过程中的注意事项

在实践中，我总结出几个重要的重构原则：

1. 小步快跑：不要试图一次性重构整个系统。我通常的做法是每次只重构一个小功能，确保每次改动都能正常编译和测试。

2. 测试先行：在开始重构前，一定要为相关代码编写足够的测试用例。我曾经因为没有充分测试，导致重构后出现了难以发现的bug。

// 示例：为策略模式编写测试
@Test
public void testVIPDiscountStrategy() {
    DiscountStrategy strategy = new VIPDiscountStrategy();
    double result = strategy.calculateDiscount(100);
    assertEquals(90.0, result, 0.001);
}

3. 版本控制：每次完成一个小重构就提交代码，这样如果出现问题可以快速回滚。