设计模式在大型项目中的实际应用案例-源码库

设计模式在大型项目中的实际应用案例：从理论到实战的完整指南

作为一名在大型电商平台工作多年的架构师，我经常被问到：“设计模式真的有用吗？在实际项目中该怎么用？”今天我就通过几个真实的项目案例，分享设计模式如何帮助我们解决复杂业务问题，以及在实际应用中需要注意的坑。

1. 工厂模式在支付系统中的应用

在我们的电商平台中，需要对接微信支付、支付宝、银联等多种支付渠道。最初我们使用大量的if-else来判断支付类型，代码维护起来简直就是噩梦。

通过引入工厂模式，我们成功解决了这个问题：


// 支付接口
public interface Payment {
    PayResult pay(Order order);
    RefundResult refund(Order order);
}

// 具体支付实现
public class WechatPayment implements Payment {
    // 实现微信支付逻辑
}

public class Alipayment implements Payment {
    // 实现支付宝支付逻辑
}

// 支付工厂
public class PaymentFactory {
    public static Payment createPayment(PaymentType type) {
        switch(type) {
            case WECHAT:
                return new WechatPayment();
            case ALIPAY:
                return new Alipayment();
            default:
                throw new IllegalArgumentException("不支持的支付类型");
        }
    }
}

踩坑提示：工厂类中的switch-case随着支付渠道增加会变得臃肿，我们后来改用了Spring的BeanFactory来动态获取支付实现，大大提高了扩展性。

2. 观察者模式在订单状态变更中的应用

订单状态变化时需要触发多个动作：发送短信、更新库存、记录日志、推送消息等。如果把这些逻辑都写在订单服务里，耦合度太高了。


// 订单状态变更事件
public class OrderStatusChangeEvent {
    private Order order;
    private OrderStatus oldStatus;
    private OrderStatus newStatus;
}

// 事件监听器接口
public interface OrderEventListener {
    void onOrderStatusChange(OrderStatusChangeEvent event);
}

// 具体监听器实现
@Component
public class SmsNotificationListener implements OrderEventListener {
    @Override
    public void onOrderStatusChange(OrderStatusChangeEvent event) {
        // 发送短信通知
    }
}

@Component  
public class InventoryUpdateListener implements OrderEventListener {
    @Override
    public void onOrderStatusChange(OrderStatusChangeEvent event) {
        // 更新库存
    }
}

// 事件发布器
@Service
public class OrderEventPublisher {
    @Autowired
    private List listeners;
    
    public void publishOrderStatusChange(OrderStatusChangeEvent event) {
        for (OrderEventListener listener : listeners) {
            try {
                listener.onOrderStatusChange(event);
            } catch (Exception e) {
                // 单个监听器异常不影响其他监听器
                log.error("监听器执行失败", e);
            }
        }
    }
}

实战经验：使用观察者模式后，新增业务逻辑只需要添加新的监听器即可，订单核心代码保持简洁。但要注意监听器的执行顺序和异常处理。

3. 策略模式在促销活动中的应用

电商平台的促销活动多种多样：满减、折扣、买一赠一、组合优惠等。每种促销都有自己的计算规则。


// 促销策略接口
public interface PromotionStrategy {
    PromotionResult calculate(PromotionContext context);
}

// 具体策略实现
@Component
public class FullReductionStrategy implements PromotionStrategy {
    @Override
    public PromotionResult calculate(PromotionContext context) {
        // 满减计算逻辑
    }
}

@Component
public class DiscountStrategy implements PromotionStrategy {
    @Override
    public PromotionResult calculate(PromotionContext context) {
        // 折扣计算逻辑
    }
}

// 策略上下文
@Service
public class PromotionContext {
    @Autowired
    private Map strategyMap;
    
    public PromotionResult execute(String strategyType, PromotionContext context) {
        PromotionStrategy strategy = strategyMap.get(strategyType);
        if (strategy == null) {
            throw new IllegalArgumentException("不支持的促销类型");
        }
        return strategy.calculate(context);
    }
}

重要提醒：策略模式让促销逻辑清晰分离，但要注意策略的注册和管理。我们使用Spring的@Qualifier注解来精确注入特定策略。

4. 单例模式在配置管理中的应用

系统配置需要在全局范围内共享且只初始化一次，单例模式是最佳选择。


@Component
public class SystemConfig {
    private static volatile SystemConfig instance;
    private Properties configs;
    
    private SystemConfig() {
        // 加载配置文件
        loadConfig();
    }
    
    public static SystemConfig getInstance() {
        if (instance == null) {
            synchronized (SystemConfig.class) {
                if (instance == null) {
                    instance = new SystemConfig();
                }
            }
        }
        return instance;
    }
    
    public String getConfig(String key) {
        return configs.getProperty(key);
    }
}

踩坑经验：在Spring环境中，通常直接使用@Configuration和@Bean来管理单例，双重检查锁定的方式在现代Java中已经很少使用。