C # 6.0의 새로운 Null 조건부 연산자는 Demeter of Laws에 적용됩니까?

데메테르 의 법칙은 다음과 같이 말합니다.

• 각 장치에는 다른 장치에 대한 정보가 제한적이어야합니다. 현재 장치와 "가까운"장치 만 있습니다.
• 각 부대는 친구들과 만 대화해야합니다. 낯선 사람과 이야기하지 마십시오.
• 가까운 친구와 만 대화하십시오.

C # 6.0은 null 조건부 연산자 라는 새로운 연산자를 도입했습니다 . IMHO, 코딩이 쉬워지고 가독성이 향상됩니다. 그러나 클래스 필드를 탐색하는 것이 더 쉽고 이미 null을 확인하는 것처럼 더 많은 결합 코드를 작성하는 것이 더 쉽습니다 var x = A?.B?.C?.D?.E?.F?.

이 새로운 운영자가 데메테르 법칙에 위배된다고 말하는 것이 맞습니까?

이 새로운 운영자가 데메테르 법칙에 위배된다고 말하는 것이 맞습니까?

아니요 ^*

^* null 조건부 연산자는 언어 및 .NET 프레임 워크 내의 도구입니다. 모든 도구는 주어진 응용 프로그램의 유지 관리 성을 손상시킬 수있는 방식으로 남용되고 사용될 수 있습니다.

그러나 도구 가 남용 될 수 있다고해서 반드시 도구 가 남용 되거나 해당 도구 가 보유 할 수있는 특정 원칙을 위반하는 것은 아닙니다.

Demeter의 법칙 및 기타는 코드 작성 방법 에 대한 지침 입니다. 도구가 아닌 인간을 대상으로합니다. 따라서 C # 6.0 언어에 새로운 도구가 있다는 사실이 코드를 작성하고 구성 하는 방법에 반드시 영향을 미치지는 않습니다 .

새로운 도구를 사용하면 코드를 유지 관리하는 사람이 폭력적인 정신병자라면 ... 으로 평가해야합니다 . 이것은 다시 사용되는 도구가 아니라 코드를 작성하는 사람을위한 지침입니다.

일종의.

하나의 액세스 ( a?.Foo) 만 수행하는 경우 다음과 같습니다.

a == null ? null : a.Foo

대부분의 사람들이 동의하는 것은 데메테르 법칙을 위반하지 않습니다. 그 시점에서 가독성을 향상시키는 것은 단지 구문 설탕입니다.

그것보다 더 중요한 것은 아마도 Demeter의 법칙에 위배 될 것입니다. 그리고이 기능은 이런 종류의 사용을 촉진시키는 경향이 있습니다. 심지어 위의 "좋은"사용법만으로는 이러한 종류의 언어 변경을 보증하기에 충분하지 않기 때문에 덜 명확한 사용법을 지원하기를 기대합니다.

그러나 데메테르의 법칙은 그 자체로 법이 아니라 더 많은 지침이라는 것을 기억할 가치가 있습니다. 많은 코드가 그것을 위반하고 잘 작동합니다. 때로는 디자인이나 코드의 단순성이 데메테르 법칙을 위반함으로써 발생하는 위험보다 더 가치가 있습니다.

아닙니다. 운영자 자신과 그에 대한 많은 체인 사용을 고려해 봅시다.

그 자체로 .?A클래스에 대한 지식과 동일한 양의 지식에 의존합니다 .A != null. A속성이 존재 한다는 사실을 알아야 하고와 비교할 수있는 값을 반환합니다 null.

우리는 유형 속성이 그렇게한다면 이것이 Demeter의 법칙을 위반한다고 주장 할 수 있습니다. 우리는 A구체적인 유형으로 강요받지 않아도 됩니다 (그 값은 파생 된 유형 일 수 있음). 여기의 커플 링은 최소입니다.

이제 생각해 보자 var x = A?.B?.C?.D?.E?.F.

어떤 수단 Anull이 될 수있다, 또는이 할 수있는 유형이어야합니다 B널 (null)이거나 가질 수있는 유형이어야 재산 C등의 형태까지에, 속성을 Enull 일 수 또는 수 프로퍼티 인 뭔가 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의 법칙을 위반하지 않는 코드를 사용하고 있습니다. 다음.

객체는 행동을 캡슐화하거나 데이터를 보유 할 목적으로 생성 될 수 있으며, 외부 코드와 공유되거나 생성자가 개인적으로 보유 할 목적으로 생성 될 수 있습니다.

행위를 캡슐화하기 위해 (공유 여부에 관계없이) 또는 외부 코드와 공유하기 위해 (행위 또는 데이터를 캡슐화하든) 생성되는 객체는 일반적으로 표면 인터페이스를 통해 액세스해야합니다. 그러나 데이터 보유 오브젝트가 작성자가 독점적으로 사용할 수 있도록 작성되는 경우 "심층적 인"액세스를 피하는 일반적인 De- 법인 이유는 적용되지 않습니다. 객체에 데이터를 저장하거나 조작하는 클래스의 일부가 다른 코드를 조정해야하는 방식으로 변경되면 위에서 언급 한 것처럼 객체가 생성 되었기 때문에 이러한 코드가 모두 업데이트되도록 보장 할 수 있습니다. 한 클래스의 독점 사용.

내가 생각하는 동안?. 연산자는 아마도 더 잘 설계되었을 수 있습니다. 개체가 중첩 된 데이터 구조를 사용하는 충분한 상황이있을 수 있습니다. 운영자는 Demeter의 법칙에 의해 표현 된 원칙을 위반하지 않는 많은 사용 사례를 가지고 있습니다. LoD를 위반하는 데 사용될 수 있다는 사실은 "."보다 나쁘지 않기 때문에 운영자에 대한 논쟁으로 간주되어서는 안됩니다. 그 점에서 운영자.