多态必须依托抽象类或接口实现：抽象类定义“是什么”及通用行为，接口划定“能做什么”的横向能力，多态通过声明类型与实际类型的分离统一调度。
多态不是孤立的概念，它必须依托抽象类或接口才能落地。真正实用的代码里，三者往往是协同出现的：抽象类定骨架和共性逻辑，接口划能力边界，多态负责统一调度。
用抽象类做顶层模板，子类专注实现细节
抽象类适合表达“是什么”+“有哪些通用行为”。比如定义一个Animal抽象类，声明name、age字段和eat()抽象方法，再提供sleep()这种所有动物都一样的具体方法。子类如Dog、Cat继承它，只管重写eat()，不用重复写sleep()。这样既避免了代码冗余，又为多态提供了统一的编译期类型。
用接口补充横向能力，支持一个类具备多重身份
接口解决的是“能做什么”，而且可以叠加。比如Dog除了是Animal，还能Swim、Guard。这时就让Dog同时extends Animal并implements Swim, Guard。调用方可以用Animal a = new Dog()走基础行为，也可以用Swim s = new Dog()调游泳动作——两种引用指向同一个对象，靠的就是多态的运行期绑定。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
多态调用时，类型决定可见范围，对象决定实际行为
关键在理解“声明类型”和“实际类型”的分离：
-
Animal a = new Dog();→ 只能调用Animal里声明的方法（包括继承来的），但执行的是Dog重写后的版本 -
Swim s = new Dog();→ 只能调用Swim接口里的方法，哪怕Dog还有其他能力也看不见 - 如果需要访问子类特有方法（比如
Dog.bark()），必须向下转型：((Dog) a).bark()，但要先用instanceof检查，否则可能抛异常
设计时优先选接口，有共性逻辑再加抽象类
这不是教条，而是从演化角度出发的实际建议：
- 一开始只有行为契约，就只定义接口（如
Playable、Serializable） - 后续发现多个实现类共享大量代码（比如日志、校验、连接池管理），再提取一个抽象实现类（如
AbstractPlayable） - 最终形成“接口定义能力 → 抽象类提供默认实现 → 具体类按需定制”的三层结构，多态自然贯穿始终
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
