工厂方法模式通过抽象类型返回值和多态实现创建与使用的分离：工厂返回接口或抽象类引用，调用方依赖接口编程，运行时动态绑定具体子类，新增产品只需扩展实现和工厂分支，业务代码零修改。
工厂方法模式靠多态实现“创建什么”和“怎么用”的分离——工厂返回抽象类型引用，运行时自动绑定到具体子类，调用方只认接口，不碰实现。
用抽象类型统一返回值
工厂方法的返回类型必须是接口或抽象类，比如 PaymentProcessor createProcessor(String type)，而不是 AlipayProcessor 或 WechatProcessor。这样调用方拿到的始终是 PaymentProcessor 类型的引用，后续所有方法调用（如 process()）都走动态绑定，实际执行哪个子类逻辑，由运行时对象决定。
- 避免返回 Object 或裸泛型，否则强转破坏类型安全，也失去多态意义
- 接口比抽象类更推荐——契约轻量、无单继承限制、聚焦行为约定
- 抽象类适合有共用字段或默认初始化逻辑的场景，但子类必须真正需要继承它
让子类各自实现，互不干扰
每个具体产品类（如 AlipayProcessor、PayPalProcessor）都实现同一接口，重写相同方法签名，但内部逻辑完全独立。比如 process() 在支付宝里调 SDK，在 PayPal 里发 HTTP 请求——调用方不用改一行代码，就能切换行为。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 不要在子类里覆盖父类非 abstract 方法来“微调”，容易违背里氏替换原则
- 通用逻辑（如日志、重试、参数校验）应抽到工具类或装饰器中，而非塞进某个子类
- 若多个子类共享初始化步骤，可放在抽象基类构造函数里，由 super() 统一触发
把选择逻辑锁进工厂，业务代码零修改
新增一种支付方式，比如加个 ApplePayProcessor，只需两步：一是让它实现 PaymentProcessor 接口；二是修改工厂内部判断（比如加个 else if ("applepay") 分支）。所有使用 PaymentProcessor 的业务代码，包括 Controller、Service、测试用例，全部无需改动。
- 工厂本身可以是简单静态方法，也可以是接口+多个具体工厂类（如 AlipayFactory、PayPalFactory），后者更符合开闭原则
- 参数可用字符串、枚举或配置项驱动，便于从外部控制（如 application.yml 中配 payment.type=alipay）
- 配合 Spring，还能用 @Conditional 或 BeanFactory 实现自动注入，测试时直接换 MockProcessor
关键一步：用父类引用指向子类实例
多态生效的前提是声明类型与实际类型分离。必须写成 PaymentProcessor p = factory.create("alipay"); p.process(order);，而不是 AlipayProcessor p = ...。前者编译期检查接口方法是否存在，运行期才确定调哪个子类的 process()——调试时能看到变量显示为 PaymentProcessor，但实际对象是 AlipayProcessor@4a5d1a。
- 如果直接 new 具体类或用具体类型接收，就又回到紧耦合，工厂和多态都失去意义
- 这种引用关系不是语法糖，是 JVM 运行时机制：方法调用查虚方法表（vtable），动态分派
- 这也是为什么单元测试能轻松替换实现——只要 mock 实现了同一接口，注入后行为自然改变
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
