返回抽象类型（如接口）是支持扩展的最简路径，通过工厂或策略模式解耦创建逻辑，结合泛型保留类型信息，避免向下转型，用职责清晰的接口设计保障多态稳定。
直接用接口或抽象类作为方法返回值类型，是让代码天然支持扩展的最简路径。它不依赖配置、不引入框架，只靠语言原生机制，就能把“新增类型”变成加个类、改个工厂的事。
返回抽象类型，隐藏具体实现
方法对外只承诺一个统一契约，内部可自由切换实现。调用方按接口使用，不感知背后是哪个子类。
- 写一个 Shape createShape(String type)，返回 Shape 接口，内部根据 type 返回 Circle、Rectangle 或后续新增的 Triangle
- 调用方只需调用 shape.draw()，无需 if-else 判断类型，也不用修改已有代码
- 新增图形时，只加新类 + 在工厂里加一行分支，其他地方零改动
结合泛型约束类型边界
纯接口返回虽灵活，但可能丢失具体类型信息；泛型可在保持多态的同时保留编译期类型推断能力。
- 定义 <T> T getVehicle(String type)，调用时可明确写出 Car car = factory.getVehicle("car")
- 避免运行时强制转型，也规避泛型擦除导致的反射或序列化问题
- 适用于需要在调用侧做类型特有操作（如 car.startEngine()），又不想破坏多态契约的场景
用工厂或策略模式组织返回逻辑
把“创建什么”的决策从业务主流程中抽离，让返回值多态真正落地为可维护结构。
立即学习“Java免费学习笔记（深入）”；
- 避免在 service 方法里写一堆 new Dog() / new Cat()，而是委托给专门的 AnimalFactory
- 工厂内部可用 Map<String, Supplier<Animal>> 注册不同构造逻辑，新增类型只需注册，不碰分支语句
- 策略模式下，返回值可能是不同算法实现（如 PaymentStrategy），调用方只关心 execute()，不关心是微信还是支付宝
警惕向下转型，优先通过接口扩展满足特有需求
一旦发现总要 cast 到子类才能调用方法，说明接口设计没覆盖真实需求。
- 不要写 ((Dog) animal).bark()，而应考虑在 Animal 接口加 makeSound()，或拆出 Barkable 子接口
- 若某行为只属于部分子类（如“能飞”），就定义 Flyable 接口，让 Bird 和 Airplane 实现，而非让所有 Animal 都承担
- 接口职责越清晰，返回值多态越稳定，扩展时越少牵连
