应使用泛型、接口抽象和领域建模替代硬编码强转：用泛型统一容器与操作逻辑，以接口+多态替代条件判断+强转，用record或dto替代松散map/jsonobject，仅在必要窄场景谨慎使用instanceof。
直接用泛型、接口抽象和领域建模替代硬编码的类型强转，能从根源上消除这类坏味道。强转本身不是错误，但大量出现往往意味着设计割裂——行为与类型解耦不足、职责模糊、多态未被有效利用。
用泛型统一容器与操作逻辑
当集合或工具类频繁做 (String) obj、(User) data.get("user") 这类强转，说明类型信息在运行时才补全，编译期无法校验。重构核心是把类型参数提前声明。
- 将
Map<string object></string>替换为Map<string t></string>或更具体的UserData、Config<integer></integer>等封装类 - 工具方法如
parse(String json, Class<t> type)</t>改为<t> T parse(String json, TypeReference<t> ref)</t></t>，配合 Jackson 的TypeReference保留泛型信息 - 避免“万能”返回
Object的 DAO 方法，改为User findById(Long id)、List<order> findRecent()</order>
用接口+多态替代条件判断+强转
典型坏味道：根据字段值判断类型，再强转调用不同方法，例如：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
这暴露了类型与行为的耦合断裂。应让类型自己决定行为。
- 定义统一接口
Notifier，含send()方法 - 让
EmailNotifier、SmsNotifier实现该接口，各自封装发送逻辑 - 用工厂或策略模式按需创建具体实现，调用方只依赖
Notifier，完全无需强转 - 若需扩展（如新增微信通知），只需新增实现类，不修改原有判断逻辑
用记录类（Record）或不可变DTO替代松散Map/JSONObject
把 JSONObject 或 Map<string object></string> 当“万能数据载体”，后续靠强转取值，本质是放弃了编译期类型安全和语义表达。
- 将入参/出参建模为具体类型：如用
record UserRequest(String name, Integer age, LocalDate birthday) {}替代Map<string object></string> - 框架层（如 Spring MVC）自动完成 JSON ↔ Record 的绑定，无需手动
get("name")再强转 - IDE 能提供字段提示、编译检查、重构支持；字段名变更时自动报错，而非运行时报
ClassCastException
谨慎使用 instanceof + 强转：仅限真正需要差异化处理的窄场景
不是所有强转都要消灭。当确实需对子类型做专属操作（如对 AdminUser 额外调用 grantSystemAccess()），可保留 instanceof，但要满足两个前提：
- 该逻辑属于明确的业务分支，且无法通过接口抽象覆盖（比如权限模型中管理员有特殊能力，普通用户没有）
- 强转后立即调用专属方法，并包裹在清晰命名的方法中，如
handleAdminSpecialCase(user)，而非散落在各处 - 优先考虑用访问者模式或双分派重构复杂类型分支，避免
if-else instanceof堆砌
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
