多态需通过实践掌握：用父类/接口定义调用逻辑，子类/实现类提供具体行为，新增功能只需添加新类而不修改旧代码。

多态不是背概念背出来的，是靠动手改代码、加新功能练出来的。核心就一条：用父类或接口写调用逻辑，把具体实现交给子类或实现类去填，每次新增一种行为，只加新类、不碰老代码。

从支付场景开始练手

这是最典型也最容易上手的练习路径。先定义一个 Payment 接口，含 pay(double amount) 和 getPayType() 两个方法；再写三个实现类：WeChatPayment、AlipayPayment、UnionPayPayment，各自实现调用对应平台API的细节。最后写一个 OrderService 类，它的 processPayment(Payment p, double amt) 方法只依赖接口，不关心传进来的是谁。跑通后，再加一个 ApplePayPayment——不用改任何已有类，只要新写类+注册到工厂（或简单替换构造），就能运行。

用角色系统深化理解

建一个 Player 抽象类或接口，声明 attack() 方法；再做 Soldier、Magician、Archer 等子类，各自重写攻击逻辑（物理/魔法/远程）。写一个战斗主循环，接收 Player 类型参数并调用 attack()。你会发现，同一行 player.attack()，传入不同对象，输出完全不同。这时可以尝试加个 upgrade() 方法，让战士升阶为“重装战士”，观察多态在运行时如何响应对象类型变化。

结合规则引擎模拟业务扩展

定义一个 Rule 接口，含 matchCondition() 和 executeAction()；然后写几个规则类：DiscountRule（满200减20）、PointsRule（下单送积分）、NotifyRule（短信提醒）。主流程只需遍历规则列表，对每个 Rule 调用两个方法。新增规则？直接写新类，加进列表即可。重点体会：主流程完全不知道新规则存在，也不需要 if-else 判断类型，这就是多态支撑“即插即用”的真实手感。

注意三个实操关键点

• 向上转型要自然：写 Payment p = new WeChatPayment(); 这类语句时，别硬记语法，想想它代表“我只认支付这件事，不挑哪家平台”
• 方法重写必须严格：子类里 @Override 不是装饰，是契约——签名一致、返回类型兼容、异常范围不扩大
• 别过早抽象：第一次写两个支付类时，先复制粘贴再提取接口；等第三个出现，才回头把共性抽成接口，这样更符合真实开发节奏