日常练习

本次练习关于使用设计模式改善代码。

我把曾经我写过的代码找了出来，发现我以前写的代码，发现结构极其臃肿，并且每次修改都可能应为连锁反应导致错误。

在其中的在OrderService类中：

public class OrderService {
    public String processOrder(String orderId, String userId, 
                               String paymentType, String deliveryType, 
                               int couponId, boolean isUrgent, 
                               Map<String, Object> extraParams) {
        // 包含了订单验证、支付处理、库存检查、物流安排、优惠计算...
    }
}

我使用IDEA的Diagram工具生成方法调用关系图：
// 先用注释标记代码段
// [1] 参数验证段：87行（第1-87行）
// [2] 支付处理段：213行（第88-300行）
// [3] 库存锁定段：156行（第301-456行）
// ...

我发现方法中存在8个重复的“地址校验”逻辑块，每个约45行代码。
提取验证层：

// 创建第一个独立类：参数验证器
public class OrderValidator {
    
    // 策略模式：不同类型的验证策略
    private List<ValidationStrategy> strategies;
    
    public ValidationResult validate(OrderContext context) {
        // 将87行验证代码重构为策略集合
        return strategies.stream()
                .map(s -> s.validate(context))
                .filter(r -> !r.isValid())
                .findFirst()
                .orElse(ValidationResult.valid());
    }
}

// 策略接口
public interface ValidationStrategy {
    ValidationResult validate(OrderContext context);
}

// 具体策略：地址验证（提取重复代码）
public class AddressValidationStrategy implements ValidationStrategy {
    @Override
    public ValidationResult validate(OrderContext context) {
        // 原来45行重复代码 -> 精简为15行
        if (context.getAddress() == null) {
            return ValidationResult.invalid("地址不能为空");
        }
        // ... 其他验证逻辑
        return checkAddressFormat(context.getAddress());
    }
    
    private ValidationResult checkAddressFormat(Address addr) {
        // 抽取的公共方法
    }
}

这样就精简了大概300行的代码。

在我的代码中还有这样的结构：

// 原始代码片段
if ("credit_card".equals(paymentType)) {
    // 120行信用卡处理逻辑
    sendCreditCardRequest(order);
    logCreditCardOperation(order);
    updateCreditCardBalance(order);
} else if ("paypal".equals(paymentType)) {
    // 95行PayPal处理逻辑
    initPayPalPayment(order);
    verifyPayPalCallback(order);
    // ... 结构类似但实现不同
} else if ("campus_card".equals(paymentType)) {
    // 82行校园卡处理逻辑
    // ...
}

首先我使用策略模式解耦支付逻辑：

// 支付策略接口
public interface PaymentStrategy {
    PaymentResult pay(Order order);
    PaymentType getType();
}

// 具体策略
public class CreditCardStrategy implements PaymentStrategy {
    @Override
    public PaymentResult pay(Order order) {
        // 原120行代码重构
        PaymentProcessor processor = new CreditCardProcessor();
        return processor.process(order);
    }
}

// 策略工厂
public class PaymentStrategyFactory {
    private Map<PaymentType, PaymentStrategy> strategies;
    
    public PaymentStrategy getStrategy(PaymentType type) {
        return strategies.get(type);
    }
}

我又发现所有支付方式都有相同步骤，于是统一处理流程：

// 模板抽象类
public abstract class PaymentTemplate {
    
    // 模板方法：定义算法骨架
    public final PaymentResult execute(Order order) {
        validate(order);        // 步骤1
        PaymentResult result = doPay(order); // 抽象方法
        logPayment(result);     // 步骤3
        return result;
    }
    
    protected abstract PaymentResult doPay(Order order);
    
    protected void validate(Order order) {
        // 公共验证逻辑
    }
    
    protected void logPayment(PaymentResult result) {
        // 公共日志逻辑
    }
}

这样一整套操作下来，我的代码精简了非常多，且利于更改。