如何应用多态特性构建高扩展性的方法返回值类型解耦实战

返回抽象类型是支持扩展的最简路径：声明Shape createShape(String type)返回接口，新增图形只需加类和工厂分支；泛型<T extends Vehicle> T getVehicle(String type)兼顾多态与类型安全；工厂模式解耦创建逻辑。

直接用父类或接口作为返回值类型，是让方法天然支持扩展的最简路径。它不依赖配置、不引入框架，只靠语言原生机制就能把“新增类型”变成加个类、改个工厂的事。

返回值声明为抽象类型，隐藏具体实现

方法对外只承诺一个统一契约，内部自由切换实现。调用方按接口使用，不感知背后是哪个子类。

• 写一个 Shape createShape(String type)，返回 Shape 接口，内部根据 type 返回 Circle、Rectangle 或后续新增的 Triangle
• 调用方只需 shape.draw()，无需 if-else 判断类型，也不用修改已有代码
• 新增图形时，只加新类 + 在工厂里加一行分支，其他地方零改动

结合泛型约束返回类型边界

纯接口返回虽灵活，但可能丢失具体类型信息；泛型可在保持多态的同时保留编译期类型推断能力。

• 定义 <T extends Vehicle> T getVehicle(String type)，调用时可明确写出 Car car = factory.getVehicle("car")
• 避免运行时强制转型，也规避泛型擦除导致的反射或序列化问题
• 适用于需要在调用侧做类型特有操作（如 car.startEngine()），又不想破坏多态契约的场景

用工厂或策略模式组织返回逻辑

把“创建什么”的决策从业务主流程中抽离，让返回值多态真正落地为可维护结构。

• 避免在 service 方法里写一堆 new Dog() / new Cat()，而是委托给专门的 AnimalFactory
• 工厂内部可用 Map
• 策略模式下，返回值可能是不同算法实现（如 PaymentStrategy），调用方只关心 execute()，不关心是微信还是支付宝

警惕向下转型，优先通过接口扩展满足特有需求

一旦发现总要 cast 到子类才能调用方法，说明接口设计没覆盖真实需求。

• 不要写 ((Dog) animal).bark()，而应考虑在 Animal 接口加 makeSound()，或拆出 Barkable 子接口
• 若某行为只属于部分子类（如“能飞”），就定义 Flyable 接口，让 Bird 和 Airplane 实现，而非让所有 Animal 都承担
• 接口职责越清晰，返回值多态越稳定，扩展时越少牵连