基于参数对象Foo，Bar构造函数链式调用DateTime的format是否违反迪米特法则？

场景代码 #

实现CustomInterface的参数对象Foo #

class Foo implements CustomInterface{
   function dateTime():\DateTimeInterface{}
}

依赖Foo的Bar类 #

class Bar{
   public function __construct(CustomInterface $interface){
      $this->field = $interface->dateTime()->format('Ymd');
   }
}

核心疑问 #

• 在Bar的构造函数中调用$interface->dateTime()->format('Ymd')是否违反迪米特法则？
• 若调用链最终返回字符串、布尔值这类“最终结果”，是否仍存在违规问题？
• 结合「不可变数据结构/纯数据结构可直接暴露内部，迪米特法则不适用」的补充规则，该场景该如何判定？

结论与分析 #

这个场景完全不违反迪米特法则，原因如下：

1. 区分「业务对象」和「数据结构」是关键
   迪米特法则的约束核心是针对封装了复杂业务行为的对象，目的是降低对象间的耦合度。而你的Foo是参数对象（纯数据结构），它的职责就是打包、承载并暴露相关数据，这类结构本就不需要隐藏内部细节，迪米特法则对其不适用——数据结构的设计初衷就是方便外部获取所需数据。

2. 调用链的性质是「数据获取」而非「业务行为传递」
   迪米特法则反对的调用链，是指业务对象之间的行为依赖传递（比如A调用B的方法拿到C，再调用C的业务方法，导致A依赖了B和C两个对象）。但你这里的$interface->dateTime()->format(...)，本质是从参数对象中取出数据对象，再格式化得到最终字符串，属于纯粹的数据获取操作，并非业务行为的链式调用，不存在过度耦合的问题。

3. 不可变/数据结构的补充规则进一步佐证
   即便Foo内部的DateTime是可变对象，你也只是读取并格式化它的状态，没有修改其内部；如果是不可变结构，那就更不存在状态被篡改的风险。数据结构的核心价值就是暴露内部数据，迪米特法则的约束从来不是为了限制这类数据访问行为。

另外，你提到无法直接传入DateTime对象（因为Foo还有Bar需要的其他字段），这种用法完全合理——参数对象的设计目的就是打包多个相关参数，避免方法参数过多，这本身就是符合设计原则的，和迪米特法则没有冲突。

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