Java设计模式实战：单例、工厂方法与抽象工厂的演进与抉择

1. 单例模式电商系统中的全局配置管理在电商系统架构演进过程中单例模式就像一位严谨的仓库管理员确保全局配置的唯一性。想象你正在开发一个日均PV过百万的中型电商平台系统中有几十个服务需要读取数据库连接配置、第三方支付密钥等敏感信息。如果每个服务都自己创建配置对象不仅浪费内存更可能导致配置不一致引发支付失败等严重问题。我曾在实际项目中遇到过这样的坑由于日志服务在多处实例化导致日志文件被重复写入。后来采用双重检查锁实现单例后问题迎刃而解。来看这段电商场景的线程安全实现public class PaymentConfig { private static volatile PaymentConfig instance; private String apiKey; private String merchantId; private PaymentConfig() { // 初始化支付配置 this.apiKey loadFromSecureVault(); this.merchantId EC001; } public static PaymentConfig getInstance() { if (instance null) { synchronized (PaymentConfig.class) { if (instance null) { instance new PaymentConfig(); } } } return instance; } }这种实现方式有三大优势延迟初始化只有在首次调用getInstance()时才创建对象线程安全通过volatile和synchronized双重保障性能优化后续调用直接返回实例避免同步开销但在微服务架构下单例模式需要调整。当系统拆分为多个服务时传统的JVM级单例就失效了。这时可以采用将配置移至分布式配置中心如Nacos通过Bean注解在Spring容器中维护单例使用Redis实现跨进程的单例控制2. 工厂方法模式订单处理器的动态创建当电商系统开始支持多种订单类型普通订单、预售订单、拼团订单时工厂方法模式就像一条智能生产线。以订单处理为例每种订单的创建逻辑差异很大普通订单需要校验库存预售订单要检查尾款支付时间拼团订单需验证成团状态先定义抽象创建器public abstract class OrderFactory { public abstract Order createOrder(OrderRequest request); // 公共校验逻辑 protected boolean validateCommon(OrderRequest request) { // 基础校验逻辑... } }具体工厂实现差异化创建public class GroupBuyOrderFactory extends OrderFactory { Override public Order createOrder(OrderRequest request) { validateCommon(request); // 拼团特有校验 if (!GroupBuyService.isValid(request.getGroupId())) { throw new IllegalStateException(拼团已失效); } return new GroupBuyOrder(request); } }工厂方法模式的精妙之处在于符合开闭原则新增订单类型只需扩展新工厂逻辑隔离每种订单的创建规则封装在专属工厂便于测试可以mock特定工厂进行单元测试在架构演进过程中我们发现当订单类型超过10种时会出现工厂类爆炸的问题。这时可以引入「工厂的工厂」——用Map维护工厂实例public class OrderFactoryProducer { private static MapOrderType, OrderFactory factories new EnumMap(OrderType.class); static { factories.put(OrderType.NORMAL, new NormalOrderFactory()); factories.put(OrderType.PRESALE, new PresaleOrderFactory()); // ...其他注册 } public static OrderFactory getFactory(OrderType type) { return factories.get(type); } }3. 抽象工厂模式跨平台UI组件库设计当电商业务需要同时支持APP、H5、小程序三端时抽象工厂就像一位全能设计师。以商品详情页为例各端的UI组件看似功能相同但实现迥异APP端使用原生组件H5端使用Vue组件小程序端使用自定义组件首先定义抽象组件族public interface UIComponentFactory { Header createHeader(); PriceDisplay createPriceDisplay(); SkuSelector createSkuSelector(); }然后为每个平台创建具体工厂public class AppComponentFactory implements UIComponentFactory { Override public Header createHeader() { return new AppHeader(); } Override public PriceDisplay createPriceDisplay() { return new AppPriceLabel(); } //...其他组件 }在渲染引擎中动态切换工厂public class DetailPageRenderer { private UIComponentFactory factory; public DetailPageRenderer(Platform platform) { switch(platform) { case APP: factory new AppComponentFactory(); break; case H5: factory new H5ComponentFactory(); break; //...其他平台 } } public void render() { Header header factory.createHeader(); header.render(); //...其他组件 } }抽象工厂模式在跨平台场景下的优势确保组件兼容性同一工厂创建的组件保证风格一致降低耦合度业务代码不依赖具体组件实现便于扩展新增平台只需实现新工厂当遇到需要支持动态主题如暗黑模式时可以将抽象工厂与桥接模式结合通过组合方式实现多维变化。4. 模式演进与选型指南在电商系统从单体到微服务的演进过程中这三种创建型模式的应用呈现出明显的阶段性特征架构阶段典型场景推荐模式注意事项单体架构配置管理、日志服务单例模式注意线程安全问题服务化订单多类型处理工厂方法模式防止工厂类膨胀微服务多端UI统一、跨服务产品族抽象工厂模式配合DI容器使用选型决策树可以帮助开发者做出合理选择是否需要保证全局唯一实例 → 单例模式是否需要创建多种类型的相似对象 → 工厂方法模式是否需要创建相关联的对象家族 → 抽象工厂模式在性能敏感场景下还需要考虑单例模式的双重检查锁性能优于同步方法工厂方法模式可以配合对象池减少new操作抽象工厂模式可能增加启动时间但运行时无负担我在重构商品搜索系统时就经历了从混乱的if-else到清晰模式组合的转变。最初直接new各种过滤器后来改用工厂方法创建不同权重策略最后用抽象工厂统一管理相关性计算组件使QPS提升了3倍。