我最近一直在反复想一件事。很多 ABAP 开发在接触OO之后，很快就能接受分层，能接受把数据库访问、界面逻辑、业务规则拆到不同的类里，也能接受Unit Test、依赖注入、构造函数注入这些做法。可一旦走到Decorator这里，脑子就容易卡住。原因很简单，前面的东西都比较像架构分层，到了Decorator，讨论的已经不是单纯的分层，而是怎么在不改调用方的前提下，把对象的能力一层一层叠起来。
这件事在ABAP里尤其有意思，因为ABAP Objects一方面支持继承和接口，另一方面又明确是单继承模型，一个类只能有一个直接父类。官方文档同时也提醒过，继承层级太深，维护成本会明显上升，行为也更难预测。接口则是另外一条路，它让不同类以同一套外部契约被访问，从而形成多态。也正因为这样，接口在ABAP里并不只是mock测试对象的工具，而是构建可替换、可扩展设计的基础设施。Robert C. Martin 在DIP里强调过，高层策略不该依赖底层细节，二者都该依赖抽象。围绕DI的讨论里，也一再强调programming to interfaces与构造注入是松耦合设计的核心。(
