企业官网建设流程全解析

1. 项目概述：当策略模式遇上抽象工厂

十年前我刚入行时，总喜欢把所有业务逻辑都塞进Controller里，直到遇到一个需要支持20多种支付方式的电商项目。当第15次因为新增支付渠道而引发线上故障时，我彻底理解了设计模式的价值。今天要聊的"策略模式+抽象工厂"组合，就是我在那个血泪项目中总结出的黄金搭档。

这个组合拳主要解决的是业务规则频繁变更带来的开发痛点。比如我们有个优惠券系统，最初只有满减券，后来陆续增加了折扣券、赠品券、积分券等8种类型，每种券的计算逻辑、使用限制、风控策略都不同。如果不用设计模式，代码里会充满if-else的"屎山"，而采用策略模式定义算法族+抽象工厂管理实例创建，能使代码扩展性提升300%以上（实测数据）。

2. 核心设计思路拆解

2.1 策略模式的本质选择

策略模式的核心在于"定义算法族，分别封装，使它们可以互相替换"。在优惠券场景中，我把每种券的计算逻辑抽象为ICouponStrategy接口：

public interface ICouponStrategy { BigDecimal calculateDiscount(Order order); // 计算优惠金额 boolean checkValidity(Order order); // 校验使用条件 void postProcess(Order order); // 使用后处理 }

为什么选择接口而不是抽象类？这里有三个关键考量：

1. Java单继承限制：业务类可能需要继承其它父类 2.接口更符合"has-a"而非"is-a"的关系
2. 默认方法（Java8+）已经能实现部分代码复用

2.2 抽象工厂的协同作用

单纯用策略模式会面临实例化混乱的问题。比如满减券需要组合使用门槛金额和减免金额参数，而折扣券需要折扣比例参数。这时抽象工厂的价值就体现了：

public interface ICouponFactory { ICouponStrategy createStrategy(CouponConfig config); String getSupportedType(); // 工厂能创建的策略类型 }

每个具体工厂负责创建对应类型的策略实例，比如：

public class DiscountCouponFactory implements ICouponFactory { @Override public ICouponStrategy createStrategy(CouponConfig config) { return new DiscountStrategy(config.getDiscountRate()); } @Override public String getSupportedType() { return "DISCOUNT"; } }

关键经验：工厂方法的返回类型要声明为接口而非具体类，这是保证扩展性的关键

3. 完整实现方案

3.1 环境准备与基础架构

首先建立Maven多模块项目结构：

coupon-system ├── coupon-api // 定义接口 ├── coupon-core // 核心实现 └── coupon-client // 客户端调用

在coupon-api模块中定义核心接口，这是所有扩展的契约。特别注意要使用@FunctionalInterface注解标记策略接口，为后续Lambda优化留空间：

@FunctionalInterface public interface ICouponStrategy { BigDecimal apply(Order order); // 默认方法实现校验逻辑 default boolean validate(Order order) { return order.getAmount().compareTo(BigDecimal.ZERO) > 0; } }

3.2 策略实现示例

以满减券为例展示具体策略实现：

public class FullReductionStrategy implements ICouponStrategy { private final BigDecimal threshold; private final BigDecimal reduction; public FullReductionStrategy(BigDecimal t, BigDecimal r) { this.threshold = t.setScale(2, RoundingMode.HALF_UP); this.reduction = r.setScale(2, RoundingMode.HALF_UP); } @Override public BigDecimal apply(Order order) { if (order.getAmount().compareTo(threshold) >= 0) { return reduction; } return BigDecimal.ZERO; } @Override public boolean validate(Order order) { // 自定义校验逻辑 return order.getItems().stream() .anyMatch(i -> i.isParticipateActivity()); } }

注意金额计算必须用BigDecimal并指定精度，这是金融计算的血泪教训。曾经因为用double导致1分钱差额的线上事故。

3.3 工厂注册机制

实现一个注册式工厂管理器，避免每次新增类型都要修改客户端代码：

public class CouponFactoryRegistry { private static final Map<String, ICouponFactory> registry = new ConcurrentHashMap<>(); static { register(new DiscountCouponFactory()); register(new FullReductionCouponFactory()); // 其他工厂注册... } public static void register(ICouponFactory factory) { registry.put(factory.getSupportedType(), factory); } public static ICouponStrategy createStrategy(String type, CouponConfig config) { ICouponFactory factory = registry.get(type); if (factory == null) { throw new IllegalArgumentException("Unsupported coupon type: " + type); } return factory.createStrategy(config); } }

这种设计下，新增优惠券类型只需要：

1. 实现新的ICouponStrategy
2. 实现对应的ICouponFactory
3. 在静态块中注册工厂 完全不影响既有代码，符合开闭原则。

4. 高级优化技巧

4.1 基于Spring的自动化注册

如果项目使用Spring，可以用更优雅的方式管理工厂：

@Component public class CouponFactoryAutoRegistry { @Autowired private List<ICouponFactory> factories; @PostConstruct public void init() { factories.forEach(f -> CouponFactoryRegistry.register(f) ); } }

配合@Service注解标记具体工厂类，Spring会自动收集所有实现注入到List中。这样新增类型连注册代码都不用写了。

4.2 策略缓存优化

对于无状态的策略实例，可以使用享元模式缓存：

public class CachedCouponFactory implements ICouponFactory { private final ICouponFactory delegate; private final Map<CouponConfig, ICouponStrategy> cache = new ConcurrentHashMap<>(); public CachedCouponFactory(ICouponFactory delegate) { this.delegate = delegate; } @Override public ICouponStrategy createStrategy(CouponConfig config) { return cache.computeIfAbsent(config, delegate::createStrategy); } }

用装饰器模式包裹原有工厂，相同配置返回同一实例。实测在促销高峰期能减少30%的对象创建开销。

5. 实战中的坑与解决方案

5.1 线程安全问题

策略实现必须明确文档说明是否线程安全。曾经有个折扣券策略在calculate方法里修改了成员变量导致并发问题。建议：

• 优先设计无状态策略
• 必须用状态时添加@NotThreadSafe注解
• 在工厂创建时通过防御性拷贝保证安全：

public FullReductionStrategy safeCopy() { return new FullReductionStrategy( new BigDecimal(threshold.toString()), new BigDecimal(reduction.toString()) ); }

5.2 策略组合难题

当遇到"满减且折扣"这种组合需求时，不要修改已有策略，而是用组合策略：

public class CompositeStrategy implements ICouponStrategy { private final List<ICouponStrategy> strategies; public BigDecimal apply(Order order) { return strategies.stream() .map(s -> s.apply(order)) .reduce(BigDecimal.ZERO, BigDecimal::add); } }

注意金额叠加方式要根据业务需求调整，比如折扣应该是乘性叠加而非加性。

5.3 动态策略切换

配置中心动态调整策略时，需要处理版本兼容：

public class ReloadableStrategy implements ICouponStrategy { private volatile ICouponStrategy delegate; public void refresh(ICouponStrategy newDelegate) { this.delegate = Objects.requireNonNull(newDelegate); } // 所有方法转发给delegate... }

用volatile保证可见性，配合CopyOnWriteArrayList处理并发调用。

6. 性能优化实测数据

在百万级订单的压力测试中，对比传统if-else实现：

• 代码行数减少40%
• 新增优惠券类型的开发时间从2天缩短到2小时
• 并发性能提升15%（得益于策略对象复用）
• GC次数减少20%（无状态策略占比高）

特别是在618大促期间，这套架构支撑住了每秒3000+的优惠计算请求，没有出现任何由于代码结构导致的性能问题。