当基本类型反复承担业务含义并伴随特定行为时，应升级为对象。如phone、address等字段多处格式化校验，或多个字段总成组出现，或方法参数零散传递时，需重构；以Address为例，三步走：新建类、替换字段、测试验证；后续可加静态工厂、改为引用对象或扩展属性；但非所有字符串都需包装，避免过早继承设计。

当一个基本类型（比如字符串、数字）在代码中反复承担业务含义，又频繁伴随特定行为时，它就该升级成对象了。这不是为了炫技，而是让代码更贴近现实、更易理解、更少出错。

什么情况下该考虑这步重构

出现以下任意一种情况，就值得动手：

• 同一个字段（如 phone、address、amount）在多处被格式化、校验、拆解或拼接
• 字段值总和另一些字段一起出现（比如 start 和 end 总是一对，代表时间范围）
• 方法参数列表里反复传入多个零散的基本类型（如 String city, String street, String zip），其实它们本该属于一个整体
• 类型码只是标识用途，不驱动分支逻辑（例如血型只有 A/O/B/AB，且所有地方都只读不判断）

怎么做：三步走，稳住行为不变

以把 String address 替换为 Address 对象为例：

• 新建类：创建 Address 类，含构造函数和 getDetail()；若需修改，再加 setDetail()
• 替换字段与访问方式：把原类中的 String address 改为 Address address，所有 getAddress() 返回 address.getDetail()，所有赋值改为 new Address(...)
• 测试验证：跑通原有单元测试，确认输出完全一致——这是重构的底线

进阶处理：别止步于“有对象”，还要管好它

对象建好了，后续维护才刚开始：

• 如果发现大量 new Address("...") 重复出现，考虑加静态工厂方法（如 Address.of("...")）或引入 Builder
• 若多个地方共用同一地址实例（如用户收货地址复用），可将 Address 改为引用对象（Change Value to Reference）
• 如果 address 后来衍生出地区编码、经纬度等新属性，直接在 Address 里加字段和方法，不用动调用方——这才是封装的价值

常见误区提醒

别把简单事搞复杂：

• 不是所有字符串都要包装——临时变量、循环索引、纯配置键名，不需要
• 别一上来就设计继承体系（比如 HomeAddress / OfficeAddress），先有一个干净的 Address 类，等行为真正分化再说
• 如果这个“基本型”只是数据库字段映射，且永远不参与业务逻辑，暂时不动也合理