适配器模式不转换变量类型，而是解决接口不兼容问题——通过中间层对齐方法签名、参数结构或返回约定。例如LegacyUserAdapter实现UserDTO接口，调用旧方法适配新契约；枚举、JSON字段、数值单位等场景均遵循“语义对齐”本质。
适配器模式不直接用于“转换变量类型”，而是解决接口不兼容问题——即当已有类的方法签名、参数结构或返回约定与当前调用方期望的契约不一致时，通过中间层做语义对齐。所谓“变量的适配器”，本质是把持有旧数据结构（如 legacy DTO、第三方响应对象、枚举字段、原始 JSON 值等）的实例，包装成符合新接口要求的行为载体。
明确目标：不是转类型，而是对齐契约
Java/C# 中不存在运行时“强制转换变量类型”的适配器；适配器操作的是行为契约。例如：
- 你有一个
LegacyUser类，含getFullname()和getEmailAddr()方法； - 但新业务模块只接受实现了
UserDTO接口的对象，该接口定义为getName()和getEmail()； - 这时不能靠
(UserDTO) legacyUser强转——而要写一个LegacyUserAdapter，实现UserDTO，并在方法体内调用对应旧方法。
实战常见变量级适配场景
1. 枚举值语义不一致
第三方 API 返回字符串 "active"/"inactive"，而你的业务逻辑依赖 Status.ACTIVE/Status.INACTIVE 枚举。
适配做法：
— 定义适配器类（对象适配器），持有一个原始字符串字段；
— 实现 StatusConverter 接口，提供 toStatus() 方法，内部做 switch 映射；
— 避免在每个 service 层重复写 if-else。
2. JSON 字段名/嵌套结构不匹配
旧接口返回 {"user_name": "Alice", "contact_email": "a@b.com"}，新模型要求 name 和 email 字段。
适配做法：
— 不修改反序列化逻辑，而是封装一个 LegacyUserJsonAdapter；
— 它接收 JsonObject 或 Map<String, Object>；
— 实现 UserView 接口，getName() 返回 json.get("user_name").toString()；
— 客户端代码完全感知不到底层字段差异。
3. 数值精度或单位不一致
传感器设备上报温度为 int centigrade * 10（如 255 表示 25.5℃），而业务服务期望 double celsius。
适配做法：
— 创建 SensorTempAdapter，构造时传入原始整数；
— 实现 TemperatureReading 接口，getValue() 返回 raw / 10.0；
— 单位、舍入策略、空值处理都收口在适配器内，不污染调用方。
关键实践建议
优先用轻量方式，而非硬写 Adapter 类
— C# 中有 implicit operator，Java 中可用 record + 构造函数封装；
— 若只是字段名不同、无逻辑转换，用 Lombok 的 @Builder(builderMethodName = "ofLegacy") 或 Jackson 的 @JsonProperty("old_name") 更直接；
— 只有当存在多步转换、条件分支、异常映射或需统一生命周期管理（如 close/dispose）时，才值得建正式 Adapter。
避免“套娃式”适配
— 如 A → B → C → D 多层包装，会模糊数据来源、增加调试难度；
— 每个适配器应只负责一层语义对齐，且命名体现职责（如 V1ToV2OrderResponseAdapter）；
— 对未实现的方法，显式抛 UnsupportedOperationException，不静默返回 null 或默认值。
本质上，变量层面的适配，是把“数据容器”变成“可交互契约”。它不改变原始值，但赋予其新上下文中的意义和行为。
