在采购申请创建程序里，调用一次创建接口，就可能生成一张真实单据。我们正在验证价格判断、审批条件或错误处理时，通常只想确认程序是否做出了正确决定，并不希望每运行一次测试，就往数据库里增加一张采购申请。这种场景很适合用《天之痕》的「借物代形」来理解，我们保留原来的调用动作，却让一个受控对象代替真实对象参与执行，把不希望发生的影响挡在业务数据之外。ABAP 里没有名为「借物代形」的语言关键字，但确实有相近的开发手段。其中，测试替身最贴近「由另一个对象代替真实对象参与执行」，代理对象更贴近「由一个中间对象代表真实对象接收调用」，而模拟执行与事务隔离，更贴近「执行过程中保护真实业务状态」。这里需要把游戏效果和技术类比分开。公开的玩家资料通常把小雪的借物代形描述为一定回合内使我方免受攻击伤害的辅助法术。不同版本、移植版和修改版的细节不宜混为一谈，更不能仅凭招式名称，就断言游戏内部一定创建了一个替身实体。本文借用的是「让原本落在真实目标上的影响，经过替代或隔离而受到控制」这一思路，并不把对象代理说成游戏程序的实际实现。把这层关系讲清楚，类比就能帮助我们理解软件设计，而不会把几个名字相似、实际用途不同的机制混在一起。我们可以从一个很具体的调用关系入手。采购业务服务需要创建采购申请，传统写法可能是在业务方法内部直接调用创建接口。这样一来，判断逻辑和外部操作紧紧绑在一起。只要执行判断逻辑，就可能触发真实单据创建；想模拟创建失败，也必须设法让真实接口失败；想验证特殊返回消息，还得准备对应的系统数据。更容易控制的设计，是让业务服务依赖一个采购申请创建接口。真实实现负责连接业务系统，测试实现负责返回预先安排好的结果。业务服务只知道自己需要执行「创建采购申请」这项能力，并不直接决定由哪一个具体对象完成。/