[c#] C #에서 속성을 사용하지 않아야하는 이유는 무엇입니까?

2009 년에이 조언은 Who Moved My Cheese 품종을 헐뜯는 것처럼 보였습니다 . 오늘날, 그것은 거의 우스꽝스럽게 쓸모가 없습니다.

많은 답변이 발끝으로 튀어 나오는 것처럼 보이지만 정면으로 다루지는 않는 매우 중요한 점 중 하나는 이러한 속성의 “위험” 이 프레임 워크 디자인의 의도적 인 부분이라는 것입니다!

예, 속성은 다음을 수행 할 수 있습니다.

• getter 및 setter에 대해 다른 액세스 수정자를 지정하십시오. 이것은 분야에 비해 장점 입니다. 일반적인 패턴은 공개 getter와 보호 또는 내부 setter를 갖는 것입니다. 이는 필드만으로는 달성 할 수없는 매우 유용한 상속 기술입니다.

• 예외를 던집니다. 현재까지 이것은 특히 데이터 바인딩 개념이 포함 된 UI 프레임 워크로 작업 할 때 가장 효과적인 유효성 검사 방법 중 하나로 남아 있습니다. 필드 작업을 할 때 개체가 유효한 상태로 유지되도록하는 것이 훨씬 더 어렵습니다.

• 실행하는 데 오랜 시간이 걸립니다. 여기서 유효한 비교는 필드가 아닌 똑같이 긴 메서드 를 사용하는 것 입니다. 한 저자의 개인적 선호 외에 “방법이 선호 됨”이라는 문구에 대한 근거는 제공되지 않습니다.

• 후속 실행에서 getter에서 다른 값을 반환합니다. 이것은 / 호출 후 필드의 값이 이전 값과 거의 다를 것이 보장되고 예측할 수없는 필드 가있는 ref/ out매개 변수 의 장점을 칭찬하는 지점에 매우 근접한 농담처럼 보입니다 .refout

  우리가 어떤 심성 커플 링 단일 스레드 액세스의 경우 특정에 대해 이야기 (실제적으로 교육)하는 경우,있어 꽤 잘 이해 가 가시 상태 변경 부작용이 그냥 나쁜 속성 디자인 있다는, 어쩌면 내 기억이다 페이딩이지만 DateTime.Now매번 동일한 가치가 나올 것으로 예상하고 사용하는 사람들의 예를 기억할 수없는 것 같습니다 . 적어도 그들이 가설과 같이 심하게 망쳐 놓지 않았을 경우는 없습니다 DateTime.Now().

• 눈에 띄는 부작용을 유발합니다. 물론 속성이 처음에 언어 기능으로 발명 된 이유입니다. Microsoft의 자체 Property Design 지침에 따르면 setter 순서는 중요하지 않습니다 . 그렇지 않으면 시간적 결합을 의미 합니다. 확실히 필드와 시간적 결합을 달성 할 수는 없지만, 일부 메서드가 실행될 때까지 필드만으로는 의미있는 동작을 전혀 발생시킬 수 없기 때문입니다.

  속성 접근 자는 작업이 수행되기 전에 개체를 유효한 상태로 강제 설정하여 특정 유형의 시간적 결합을 방지 하는 데 실제로 도움이 될 수 있습니다. 예를 들어 클래스에 a StartDate및EndDate 다음 설정, EndDate(가) 이전에 StartDate강제 할 수 StartDate뿐만 아니라 다시. 이벤트 기반 사용자 인터페이스의 명백한 예를 포함하여 다중 스레드 또는 비동기 환경에서도 마찬가지입니다.

속성이 수행 할 수있는 기타 작업은 포함 할 수없는 필드입니다.

• 지연 로딩 , 초기화 순서 오류를 방지하는 가장 효과적인 방법 중 하나입니다.
• 변경 알림 .MVVM 아키텍처의 .
• 상속 , 예를 들어 추상 정의Type 또는 Name파생 클래스 은 흥미롭지 만 그럼에도 불구하고 자신에 대한 지속적인 메타 데이터를 제공 할 수 있습니다.
• 차단위의 덕분에 .
• 인덱서 , COM interop으로 작업해야했던 모든 사람과 불가피한 Item(i)호출 분출은 멋진 것으로 인식 할 것입니다.
• PropertyDescriptor로 작업 디자이너의 작성 및 일반적으로 XAML 프레임 워크 필수적이다.

Richter는 분명히 다작의 저자이며 CLR 및 C #에 대해 많이 알고 있지만, 그가 원래이 조언을 썼을 때처럼 보입니다. 그는 단지 오래된 습관을 버리고 싶지 않았고 C #의 관습을 받아들이는 데 어려움을 겪고있었습니다 (예 : C ++와 비교).

이것이 의미하는 바는 그의 “유해한 것으로 간주되는 속성”주장은 본질적으로 단일 진술로 요약됩니다. 속성은 필드처럼 보이지만 필드처럼 작동하지 않을 수도 있습니다. 그리고 성명서의 문제 는 사실이 아니 거나 기껏해야 오해의 소지가 있다는 것입니다. 속성 은 필드처럼 보이지 않습니다 . 적어도 필드처럼 보이지 않아야 합니다.

이 두 가지 매우 다른 CLR 언어에 의해 공유 유사한 규칙과 C #에서 강력한 코딩 규칙, 그리고 당신이 그들을 따르지 않는 경우의 FxCop은 비명합니다 :

1. 필드한다 항상 개인 수 결코 공개.
2. 필드는 camelCase로 선언해야합니다. 속성은 PascalCase입니다.

따라서 Foo.Bar = 42속성 접근 자인지 필드 접근 자 인지 에 대한 모호성이 없습니다 . 속성 접근 자이며 다른 메서드처럼 취급되어야합니다. 느릴 수 있고 예외가 발생할 수 있습니다. 이것이 추상화 의 특성입니다 . 반응하는 방법을 선언하는 클래스의 재량에 달려 있습니다. 클래스 디자이너는 최소한의 놀라움의 원칙을 적용해야하지만 호출자는 속성이 주석에 표시된 것을 제외하고는 어떤 것도 가정해서는 안됩니다. 그것은 의도적 인 것입니다.

속성의 대안은 모든 곳에서 getter / setter 메서드입니다. 이것이 Java 접근 방식이며 처음부터 논란 이되었습니다 . 그것이 당신의 가방이라면 괜찮지 만 우리가 .NET 진영에 들어가는 방식은 아닙니다. Fowler가 Syntactic Noise 라고 부르는 것을 피하기 위해 적어도 정적으로 형식화 된 시스템의 범위 내에서 시도 합니다. 우리는 추가 괄호, 추가 get/ set사마귀 또는 추가 메서드 서명을 원하지 않습니다. 명확성을 잃지 않고 피할 수있는 경우가 아닙니다.

당신이 좋아하는 것을 말하되, foo.Bar.Baz = quux.Answers[42]는 항상보다 읽기 쉬울 것 foo.getBar().setBaz(quux.getAnswers().getItem(42))입니다. 그리고 하루에 수천 줄을 읽을 때 차이가 있습니다.

_{(그리고 위 단락에 대한 당신의 자연스러운 반응이 “읽기 어렵지만 여러 줄로 나누면 더 쉬울 것”이라고 말하는 것이면 , 요점 을 완전히 놓쳤다 고 말하는 것이 유감입니다 .)}

답변

public class WorkerUsingMethod
{
   // Explicitly obvious that calculation is being done here
   public int CalculateResult()
   {
      return ExpensiveLongRunningCalculation();
   }
}

public class WorkerUsingProperty
{
   // Not at all obvious.  Looks like it may just be returning a cached result.
   public int Result
   {
       get { return ExpensiveLongRunningCalculation(); }
   }
}

public int Result
{
   get
   {
       m_numberQueries++;
       return m_result;
   }
}