数据处理职责划分：应由调用方还是被调用对象处理数据？

不要在两个极端里二选一：既不用为了死守封装原则，把所有调用方的零散定制逻辑全塞进核心对象，把核心类撑成几千行的“上帝对象”；也不要为了省事儿直接把对象内部原始状态全透传出去，彻底破坏封装带来的一致性保障。

• 逻辑依赖对象未对外公开的私有状态、核心不变量约束：比如订单类计算实付金额，需要用到内部存储的优惠券核销规则、会员折扣梯度、满减叠加逻辑这些不对外暴露的校验规则，这种逻辑必须内聚在对象内部。如果直接把原始订单条目、优惠券标识扔给调用方自行计算，调用方拿不到完整的约束规则，很容易算出不符合业务规则的错误结果。
• 逻辑属于对象的核心职责，且被两个及以上调用方复用：比如用户类的「判断账号是否已完成实名认证」逻辑，会被内容展示、交易风控、活动准入等多个模块调用，这种就应该做成公共方法，避免每个调用方重复实现逻辑，后续规则变动时出现多端逻辑不一致的问题。
• 处理过程需要保障对象自身状态的一致性：比如购物车的「新增商品」操作，内部要同步做库存校验、重复商品数量合并、关联优惠重算，这时候如果直接把购物车内部的商品列表暴露给调用方自行修改，很容易产生跳过校验的脏数据，破坏对象状态的合法性。

• 处理逻辑是单个调用方独有的定制需求：比如运营后台导出订单时，需要把订单创建时间格式化为yyyy年MM月dd日 HH点的特殊格式，其余所有调用方都不需要这个格式，就完全没必要在订单类里新增一个仅给导出场景用的格式化方法，直接返回标准的时间对象，由导出逻辑自行做格式转换即可。
• 处理逻辑不涉及对象核心约束，只是对公开字段的二次加工：比如前端页面需要在用户昵称后拼接VIP等级标识，只要拿到公开的昵称、VIP等级两个字段就能完成拼接，不需要在用户类里新增专门给前端用的名称拼接方法。
• 处理逻辑随调用场景频繁变动：比如不同业务线的报表对订单金额的统计口径差异极大，有的要求扣减已退款金额、有的不要求，有的要求分摊跨店运费、有的不分摊，这类易变的场景化逻辑如果全塞到核心订单类里，会导致核心类快速臃肿，后续改个报表需求还要动核心交易代码，引入不必要的线上风险。

不用在“堆方法到核心类”和“透传原始数据”里二选一，可以用两个方案平衡封装性和扩展性：

• getter返回不可变的公开数据快照，不要直接返回内部可变对象的引用。比如返回的列表是只读包装类、返回的实体对象是深拷贝的不可变视图，调用方可以拿到数据做自定义加工，但无法直接修改对象内部状态，不会破坏封装的一致性保障。
• 用场景专用的包装类承接单一场景的定制逻辑，不要把零散逻辑堆到核心领域对象上。比如针对运营导出场景，可以单独封装OrderExportDTO类，接收订单返回的公开数据，在DTO层实现导出需要的格式化、口径计算逻辑，核心订单类完全不需要感知这类场景化需求。

内容的提问来源于stack exchange，提问作者cobby