抽象类Payment定义支付契约，继承实现微信、支付宝等具体支付逻辑，多态通过父类引用动态调度子类方法，结合工厂与策略模式提升扩展性与健壮性。
要写出真正体现多态、继承与抽象类深度结合的Java业务实战，关键不是堆砌语法，而是让三者在业务逻辑中自然咬合：抽象类定义不可变契约，继承实现差异化扩展，多态完成运行时动态调度。下面用一个真实感强、可直接运行的“支付系统”案例说明。
抽象类定骨架：统一行为边界
支付方式千差万别（微信、支付宝、银行卡），但所有支付都必须有“发起支付”和“验证结果”两个核心动作，且不能直接创建“支付”这个泛概念对象——这正是抽象类的典型场景。
定义 Payment 抽象类：
- 声明
abstract void pay(double money)和abstract boolean verify()—— 强制子类提供具体实现； - 提供公共方法
void logStart(String orderId)和protected String generateTraceId()—— 复用通用逻辑； - 含构造器
Payment(String channel)—— 初始化渠道名，供子类调用； - 不提供无参构造器，避免误用；
- 禁止实例化：
new Payment("xxx")编译直接报错。
继承填血肉：子类专注自身逻辑
每个具体支付方式继承 Payment，只关心“我怎么付”“我怎么验”，不重复写日志、追踪ID等共性代码。
立即学习“Java免费学习笔记（深入）”；
例如 WechatPay：
- 调用
super("微信支付")初始化父类字段； - 重写
pay()：调用微信SDK接口，打印“调用微信JSAPI下单…”； - 重写
verify()：查微信订单状态API，返回true或false； - 不重写
logStart()—— 直接复用父类； - 若需扩展（如微信特有“红包回调处理”），在子类中新增私有方法即可。
同理，AlipayPay 和 BankCardPay 各自实现，彼此隔离，互不影响。
多态跑起来：用父类引用统一调度
业务层（如订单服务）不需要知道当前是哪种支付，只面向 Payment 编程：
- 接收参数为
Payment payment类型； - 调用
payment.pay(199.9)—— 实际执行哪个子类的pay()，由传入对象的真实类型决定； - 后续调用
payment.verify()，自动绑定到对应子类实现； - 添加新支付方式（如
PuYinPay extends Payment）时，订单服务代码零修改，只需注入新实例。
这就是“开闭原则”的落地：对扩展开放（加新支付），对修改关闭（不动原有逻辑）。
实战增强点：让结构更健壮
真实项目中再加两层设计，让抽象+继承+多态真正立住：
-
工厂封装创建逻辑：用
PaymentFactory.getPayment("wechat")返回具体子类实例，避免业务层到处 new； -
策略模式融合：把
Payment当作策略接口（虽用抽象类实现），配合OrderService的process(Payment p)方法，形成清晰职责分离； -
运行时类型判断慎用：避免写
if (p instanceof WechatPay)—— 这会破坏多态，真需要差异化处理，应提取为抽象方法或回调； -
抽象类里留钩子：比如加
protected void onBeforePay() { }空方法，子类按需重写，不强制但保留扩展口。
不复杂但容易忽略。
