C＃6.0の新しいnull条件演算子は、Demeterの法則に反しますか？

デメテルの法則は次のように述べています：

• 各ユニットは、他のユニットに関する限られた知識のみを持つ必要があります。現在のユニットに「密接に」関連するユニットのみです。
• 各ユニットは、その友人とのみ会話する必要があります。見知らぬ人と話をしないでください。
• 身近な友達とだけ話してください。

C＃6.0では、null-conditional operatorと呼ばれる新しい演算子が導入されました。私見、それはコーディングを容易にし、読みやすさを向上させます。ただし、クラスフィールドをナビゲートするのが簡単で、すでにヌル（のようなものvar x = A?.B?.C?.D?.E?.F?）をチェックしているため、より結合されたコードを簡単に記述できます。

この新しいオペレーターがデメテルの法則に反すると述べるのは正しいですか？

この新しいオペレーターがデメテルの法則に反すると述べるのは正しいですか？

いいえ^*

^* null条件演算子は、言語および.NETフレームワーク内のツールです。 どのツールも、特定のアプリケーションの保守性を損なう可能性のある方法で悪用され、使用される可能性があります。

しかし、ツールが悪用される可能性があるという事実は、必ずしもツールが悪用されなければならないということではなく、ツールが保持されている特定の原則に違反していることも意味しません。

デメテルの法則などは、コードの記述方法に関するガイドラインです。ツールではなく、人間を対象としています。そのため、C＃6.0言語に新しいツールが含まれているという事実は、コードの記述方法と構造化方法に必ずしも影響を与えません。

新しいツールを使用する場合は、コードを保守することになった人が暴力的なサイコパスになった場合に...として評価する必要があります。繰り返しますが、これはコードを書いている人へのガイダンスであり、使用されているツールに関するものではありません。

並べ替え。

1回のみアクセスする場合（a?.Foo）は、次と同等です：

a == null ? null : a.Foo

ほとんどの人が同意することは、デメテルの法則に違反していないことです。その時点では、読みやすさを向上させるのは単なる構文糖です。

それ以上のものは、おそらくデメテルの法則に違反するでしょう。この機能は、そのような使用法を促進する傾向があります。上記の「良い」使用法だけでは、この種の言語の変更を保証するのに十分ではないと言えるでしょう。

とはいえ、デメテルの法則はそれ自体が法則ではなく、むしろガイドラインであることを覚えておく価値があります。多くのコードがこれに違反しており、うまく機能しています。設計やコードの単純さは、デメテルの法則に違反することによってもたらされるリスクよりも価値がある場合があります。

いいえ。それ自体の演算子と、それに対する重く連鎖した使用の両方を考えてみましょう。

それ自体.?Aは、左値が存在するクラスの知識と、メソッドによって返される型の知識の量と同じ.A != nullです。Aプロパティが存在することを知り、と比較できる値を返す必要がありますnull。

型付けされたプロパティがそうである場合、これはデメテルの法則に違反しているとのみ主張できます。A具象型として強制されることさえありません（その値は派生型である可能性があります）。ここでの結合は最小限です。

考えてみましょうvar x = A?.B?.C?.D?.E?.F。

つまり、Anullになる可能性のあるタイプ、またはnullになる可能性のあるタイプ、またはBプロパティを持つ可能性のあるタイプである必要があり、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;
    }
  }
}

これはまったく同じ。異なる要素のカップリングを使用するこのコードは、カップリングの完全なチェーンを「知る」必要がありますが、そうするためにデメテルの法則に違反しないコードを使用しており、各ユニットは次。

オブジェクトは、ビヘイビアをカプセル化したりデータを保持したりする目的で作成でき、オブジェクトは外部コードと共有したり、作成者が個人的に保持したりする目的で作成できます。

動作をカプセル化する目的（共有されているかどうか）、または外部コードと共有されている（動作またはデータをカプセル化する）ために作成されたオブジェクトは、通常、表面インターフェイスからアクセスする必要があります。ただし、データ保持オブジェクトが作成者のみが使用するために作成された場合、「ディープ」アクセスを回避するための通常のデメテルの法則の理由は適用されません。オブジェクト内のデータを格納または操作するクラスの一部が、他のコードの調整を必要とする方法で変更された場合、そのようなコードはすべて更新されることを保証することができます-上記のように、オブジェクトは1つのクラスの排他的使用。

と思いながら？演算子はおそらくより適切に設計されている可能性があります。オブジェクトがネストされたデータ構造を使用する十分な状況があります。LoDに違反する可能性があるという事実は、「。」より悪くないため、演算子に対する引数として受け取られるべきではありません。その点で演算子。