[C#] C #에서 개인 속성을 사용해야하는 이유가 있습니까?

방금 C # 속성 구문개인 액세스 수정 자 와 함께 사용할 수 있음을 깨달았습니다 .

private string Password { get; set; }

이것은 기술적으로 흥미롭지 만 개인 필드 에는 식이 훨씬 적기 때문에 언제 사용할 것인지 상상할 수 없습니다 .

private string _password;

그리고 내부적으로 얻을 수는 있지만 설정 하거나 설정할 없지만 개인 필드를 얻을 수없는 경우를 상상할 수 없습니다 .

private string Password { get; }

또는

private string Password { set; }

그러나 중첩 된 / 상속 된 클래스 의 유스 케이스가 있거나 get / set 에 속성 값을 반환하는 대신 논리 가 포함될 수 있습니다 . 속성을 단순하게 유지하고 명시 적 메소드가 논리를 수행하도록하는 경향이 있지만, 예 GetEncodedPassword().

어떤 이유로 든 C #에서 개인 속성을 사용합니까 아니면 기술적으로 가능하지만 실제로 사용되지 않는 실제 코드 구성 중 하나입니까?

추가

좋은 답변, 그들을 통해 나는 개인 재산에 대한 이러한 사용을 컬링 :

  • 개인 필드를 느리게로드해야하는 경우
  • 개인 필드에 추가 논리가 필요하거나 계산 된 값인 경우
  • 개인 필드는 디버그하기 어려울 수 있기 때문에
  • “자신에게 계약을 제시”
  • 직렬화의 일부로 노출 된 속성을 내부적으로 변환 / 단순화
  • 클래스 내에서 사용될 전역 변수 랩핑


답변

값을 캐시해야하고 지연로드하려는 경우이를 사용합니다.

private string _password;
private string Password
{
    get
    {
        if (_password == null)
        {
            _password = CallExpensiveOperation();
        }

        return _password;
    }
}


답변

내 코드에서 이것의 주요 사용법은 다른 사람들이 언급했듯이 지연 초기화입니다.

필드에 대한 개인 속성의 또 다른 이유는 개인 속성이 개인 필드보다 디버그하기가 훨씬 훨씬 쉽다는 것입니다. “이 필드는 예기치 않게 설정됩니다.이 필드를 설정 한 첫 번째 발신자는 누구입니까?”와 같은 것을 자주 알고 싶습니다. 세터에 중단 점을 놓고 이동하면 더 쉽습니다. 거기에 로깅을 넣을 수 있습니다. 거기에 성능 지표를 넣을 수 있습니다. 디버그 빌드에서 실행되는 일관성 검사를 수행 할 수 있습니다.

기본적으로 코드는 데이터보다 훨씬 강력합니다. . 필요한 코드를 작성할 수있는 모든 기술이 좋습니다. 필드를 사용하면 코드를 작성할 수 없으며 속성도 마찬가지입니다.


답변

아마도 중첩 / 상속 된 클래스의 유스 케이스가 있거나 get / set에 속성 값을 반환하는 대신 논리가 포함될 수 있습니다

속성의 getter 또는 setter에 대한 논리가 필요하지 않은 경우에도 개인적으로 사용합니다. 속성, 심지어 개인 속성을 사용하면 코드를 미래에 대비하여 나중에 필요한 경우 나중에 게터에 로직을 추가 할 수 있습니다.

속성에 결국 추가 논리가 필요할 수 있다고 생각되면 필드를 사용하는 대신 개인 속성으로 래핑하기 때문에 나중에 코드를 변경할 필요가 없습니다.


반 관련 사례 (귀하의 질문과는 다르지만), 나는 공공 재산에 개인 세터를 매우 자주 사용합니다.

public string Password
{
    get;
    private set;
}

이것은 공개 게터를 제공하지만 세터를 비공개로 유지합니다.


답변

개인용 get 전용 속성의 좋은 사용법은 계산 된 값입니다. 여러 번 개인 전용 읽기 전용 속성이 있었고 내 유형의 다른 필드에 대해 계산을 수행했습니다. 그것은 메서드에 가치가 없으며 다른 클래스에는 흥미가 없으므로 개인 재산입니다.


답변

게으른 초기화는 예를 들어 깔끔한 곳입니다.

private Lazy<MyType> mytype = new Lazy<MyType>(/* expensive factory function */);

private MyType MyType { get { return this.mytype.Value; } }

// In C#6, you replace the last line with: private MyType MyType => myType.Value;

그런 다음 한 곳에서 게으르게 인스턴스화된다는 사실을 캡슐화 this.MyType하지 않고 어디에서나 쓸 수 있습니다 this.mytype.Value.

부끄러운 점 중 하나는 C #이 지원 필드를 속성으로 범위 지정 (즉, 속성 정의 내에 선언)하여 필드를 완전히 숨기고 속성을 통해서만 액세스 할 수 있도록하는 것입니다.


답변

내가 생각할 수있는 유일한 사용법

private bool IsPasswordSet
{
     get
     {
       return !String.IsNullOrEmpty(_password);
     }
}


답변

속성과 필드는 일대일이 아닙니다. 속성은 클래스의 인터페이스 (공개 또는 내부 인터페이스에 대해 이야기하든)에 관한 것이며 필드는 클래스의 구현에 관한 것입니다. 속성은 필드를 노출하는 방법으로 만 보여서는 안되며 클래스의 의도와 목적을 노출하는 방법으로 보여야합니다.

클래스를 구성하는 것에 대해 소비자에게 계약을 제시하기 위해 속성을 사용하는 것과 마찬가지로 매우 유사한 이유로 계약을 제시 할 수도 있습니다. 예, 개인 속성이 의미가있을 때 사용합니다. 때로는 사유 재산이 게으른 로딩과 같은 구현 세부 사항을 숨길 수 있습니다. 속성이 실제로 여러 필드와 측면의 대기업이거나 속성이 각 호출마다 가상으로 인스턴스화되어야한다는 사실입니다 (think DateTime.Now). 수업의 백엔드에서도 스스로를 시행하는 것이 합리적 인 경우가 있습니다.