引用数据类型通过继承获得单一可延展的类型身份（如student is-a person），又可通过实现多个接口获得并列的行为身份（如robot implements movable, runnable, exportable），同名同签名方法需统一实现，同名异签名须显式区分，真实场景中应以接口组合替代多继承。
引用数据类型本身不“具备多重身份”，但通过继承与实现机制，它可以被赋予多种类型角色——这本质上是面向对象中“类型兼容性”的体现，而非对象拥有多个本体。
继承带来单一但可延展的类型身份
一个类只能 extends 一个父类，因此它在继承层面只有一个直接类型身份。比如 Student extends Person，Student 实例既是 Student 类型，也是 Person 类型（因为子类 is-a 父类），还可向上转型为 Object。这种身份是单向、线性的，靠继承链自然确立。
- 子类自动获得父类的公开/受保护成员，可用于方法调用和字段访问
- 父类引用可指向子类实例（上转型），但仅能调用父类声明的方法
- 不能绕过单继承限制去“同时是 A 和 B 两个不相关类的子类”
实现赋予并列且可叠加的行为身份
一个类可通过 implements 同时实现多个接口，每个接口代表一种契约式能力。例如：class Robot implements Movable, Runnable, Exportable —— 此时 Robot 实例在类型系统中同时是 Movable、Runnable 和 Exportable，三者地位平等、互不隶属。
- 每个接口定义一组行为规范，实现即承诺提供对应方法的具体逻辑
- 接口之间无继承关系也可共存；同一类可自由组合不同业务维度的接口
- 可通过任一接口类型变量引用该实例，调用其对应的方法
冲突处理：同名方法需显式协同
当多个接口定义了签名相同的方法（如都含 void log()），实现类必须提供唯一实现，Java 不允许歧义；若签名相同但语义不同（如返回类型或参数不同），则属于编译错误，必须通过显式接口实现来区分。
- 同名同签名 → 覆盖一次即可，所有接口共用该实现
- 同名但返回类型不同或参数列表不同 → 必须使用
InterfaceName.methodName()显式实现 - 避免在接口中滥用默认方法造成隐式冲突，优先让实现类掌握控制权
真实场景中的身份组合逻辑
用户模型常需横跨认证、支付、审核等维度，这时不应设计“User 继承 AuthUser、PaymentUser、AuditUser”，而应让具体业务类实现对应接口，例如：
AdminUser implements Authenticatable, Auditable, ExportableMerchantUser implements Authenticatable, Payable, ExportablePlatformUser implements Authenticatable, Payable, Auditable, Exportable
这样每个类型身份清晰、解耦，新增能力只需增加接口实现，不扰动已有继承结构。
