C＃6.0的新空条件运算符是否违反Demeter定律？

该德米特法律规定如下：

• 每个单元对其他单元的知识应该有限：只有与当前单元“紧密”相关的单元。
• 每个单位只能与朋友交谈；不要和陌生人说话。
• 只与您的直系朋友交谈。

C＃6.0引入了一个称为空条件运算符的新运算符。恕我直言，它使编码更容易并提高了可读性。但这也使编写更多耦合的代码变得更容易，因为更容易在已经检查了无效性的类字段中导航（类似var x = A?.B?.C?.D?.E?.F?）。

陈述这名新操作员违反Demeter法则是否正确？

陈述这名新操作员违反Demeter法则是否正确？

否^*

^*空条件运算符是语言和.NET框架中的工具。 任何工具都有可能以可能损害给定应用程序可维护性的方式被滥用和使用。

但事实上，一个工具可以被滥用并不一定意味着它已经被滥用，也不该工具侵犯任何特定原则（一个或多个）可以举行。

得墨meter耳法则和其他都是有关如何编写代码的准则。它针对的是人类，而不是工具。因此，C＃6.0语言中包含一个新工具这一事实并不一定会影响您应该如何编写和构建代码。

对于任何新的工具，你需要把它作为评价......如果谁最终维护你代码的家伙将是一个暴力精神病患者......。再次注意，这是对编写代码的人员的指导，而不是有关所用工具的指导。

有点。

如果您只进行一次访问（a?.Foo），则等效于：

a == null ? null : a.Foo

大多数人都会同意这并不违反《得墨meter耳定律》。那时，只是语法糖可以提高可读性。

除此之外，还可能违反Demeter定律，并且此功能确实会促进这种用法。我什至会说，仅上述“好的”用法不足以保证对这种语言的这种更改，因此我希望这样做是为了支持不太清楚的好的用法。

也就是说，值得记住的是，《得墨meter耳法则》本身并不是法律，而是更多的指导原则。许多代码都违反了它，并且运行良好。有时，设计或代码的简单性所带来的价值超过违反Demeter法则所带来的风险。

不。让我们既考虑运营商本身，又考虑您对其的严格使用。

.?A依赖于左值的类和方法返回的类型的知识量，也就是它本身.A != null。它需要知道该A属性是否存在，并返回可以与进行比较的值null。

我们只能说，如果键入的属性确实违反了Demeter的定律。我们甚至没有被迫具有A具体类型（它的值可以是派生类型）。这里的耦合很小。

现在让我们考虑一下var x = A?.B?.C?.D?.E?.F。

这意味着该A类型必须为可以为null的类型，或者可以具有B属性，必须为可以为null的类型或具有C属性，依此类推，直到该E属性的类型可以为null或可能F有财产。

换句话说，我们需要使用静态类型的语言来执行此操作，或者对类型松散的情况下可以返回的类型施加约束。C＃在大多数情况下使用静态类型，因此我们没有做任何更改。

如果有的话，以下代码也将违反法律：

ExplicitType x;
var b = A.B;
if (b == null)
  x = null;
else
{
  var c = b.C;
  if (c == null)
    x = null;
  else
  {
    var d = c.D;
    if (d == null)
      x = null;
    else
    {
      var e = d.E;
      if (e == null)
        x = null;
      else
        x = e.F;
    }
  }
}

哪个完全一样。此代码使用不同元素的耦合，需要“知道”整个耦合链，但是它使用的代码并没有违反Demeter定律，每个单元都具有明确定义的耦合下一个。

可以出于封装行为或保存数据的目的而创建对象，并且可以出于与外部代码共享或由其创建者私有保存的目的而创建对象。

为封装行为（无论是否共享）或与外部代码共享而创建的对象（无论它们封装行为还是数据）通常应通过其表面接口访问。但是，当创建数据保留对象以供其创建者专用时，则不适用避免“深度”访问的通常的《 Demeter of Demeter》理由。如果以需要调整其他代码的方式更改了在对象中存储或操作数据的类的一部分，则可以保证所有此类代码都得到更新，因为（如上所述），对象是为创建对象而创建的。一类的专用。

虽然我认为？操作员可能设计得更好，在很多情况下对象使用嵌套数据结构，操作员有很多用例，而这些用例不会违反Demeter法则所表达的原理。它可能被用来违反LoD的事实不应被视为反对运营商的论据，因为它并不比“。”更糟糕。运营商在这方面。