代码重构技巧与设计模式实战结合案例

代码重构技巧与设计模式实战结合案例：从混乱到优雅的蜕变之旅

大家好，我是源码库的技术博主。今天想和大家分享一个我在实际项目中遇到的代码重构案例，以及如何巧妙运用设计模式让代码焕然一新。这个案例来自一个电商系统的订单处理模块，最初代码充斥着重复逻辑和复杂条件判断，维护起来让人头疼不已。

问题发现：识别代码坏味道

当我接手这个项目时，订单处理的核心逻辑是这样的：

public class OrderProcessor {
    public void processOrder(Order order) {
        if (order.getType().equals("NORMAL")) {
            // 普通订单处理逻辑
            validateNormalOrder(order);
            calculateNormalDiscount(order);
            updateInventory(order);
            sendNormalNotification(order);
        } else if (order.getType().equals("GROUP")) {
            // 团购订单处理逻辑
            validateGroupOrder(order);
            calculateGroupDiscount(order);
            updateInventory(order);
            sendGroupNotification(order);
        } else if (order.getType().equals("FLASH")) {
            // 秒杀订单处理逻辑
            validateFlashOrder(order);
            calculateFlashDiscount(order);
            updateInventory(order);
            sendFlashNotification(order);
        }
        // 更多订单类型...
    }
}

这段代码的问题很明显：每当新增订单类型时，都需要修改这个核心类，违反了开闭原则。而且重复的库存更新逻辑散落在各个分支中，维护成本很高。

重构策略：策略模式的应用

我决定使用策略模式来解决这个问题。首先定义订单处理策略接口：

public interface OrderProcessingStrategy {
    void validate(Order order);
    void calculateDiscount(Order order);
    void sendNotification(Order order);
}

然后为每种订单类型实现具体的策略：

public class NormalOrderStrategy implements OrderProcessingStrategy {
    @Override
    public void validate(Order order) {
        // 普通订单验证逻辑
        if (order.getAmount() < 0) {
            throw new IllegalArgumentException("订单金额不能为负");
        }
    }
    
    @Override
    public void calculateDiscount(Order order) {
        // 普通订单折扣计算
        if (order.getAmount() > 100) {
            order.setDiscount(10);
        }
    }
    
    @Override
    public void sendNotification(Order order) {
        // 发送普通订单通知
        notificationService.sendEmail(order.getCustomerEmail(), "普通订单创建成功");
    }
}

工厂模式的引入

为了更方便地获取策略实例，我创建了一个策略工厂：

public class OrderStrategyFactory {
    private static Map strategies = new HashMap<>();
    
    static {
        strategies.put("NORMAL", new NormalOrderStrategy());
        strategies.put("GROUP", new GroupOrderStrategy());
        strategies.put("FLASH", new FlashOrderStrategy());
    }
    
    public static OrderProcessingStrategy getStrategy(String orderType) {
        OrderProcessingStrategy strategy = strategies.get(orderType);
        if (strategy == null) {
            throw new IllegalArgumentException("不支持的订单类型: " + orderType);
        }
        return strategy;
    }
}

模板方法模式的运用

注意到所有订单类型都需要更新库存，我使用模板方法模式来消除重复代码：

public abstract class AbstractOrderProcessor {
    // 模板方法，定义处理流程
    public final void processOrder(Order order) {
        OrderProcessingStrategy strategy = OrderStrategyFactory.getStrategy(order.getType());
        
        strategy.validate(order);
        strategy.calculateDiscount(order);
        updateInventory(order); // 公共逻辑
        strategy.sendNotification(order);
    }
    
    // 公共逻辑提取
    private void updateInventory(Order order) {
        // 库存更新逻辑
        inventoryService.updateStock(order.getItems());
    }
}

重构后的效果

经过重构，原来的混乱代码变成了：

public class RefactoredOrderProcessor extends AbstractOrderProcessor {
    // 现在只需要继承模板类，无需重复编写公共逻辑
}

踩坑提示：在实际重构过程中，我发现策略模式虽然优雅，但要注意策略对象的生命周期管理。对于有状态的策略，需要确保线程安全；对于无状态的策略，可以考虑使用单例模式来优化性能。

经验总结

这次重构让我深刻体会到：

1. 识别代码坏味道是重构的第一步
2. 设计模式不是银弹，要根据具体场景选择
3. 重构应该小步快跑，每次只改变一个方面
4. 充分的单元测试是重构的安全网

重构后的代码不仅更易于维护，扩展新订单类型也变得更加简单。希望这个案例能给大家带来启发，在遇到类似问题时能够从容应对！