개인 필드가 있거나없는 속성을 선호해야합니까?

현재 작업중 인 코드베이스에는 개인 필드 및 공용 속성을 사용하는 규칙이 있습니다. 예를 들어, 대부분의 클래스에는 다음과 같이 멤버가 정의되어 있습니다.

// Fields
private double _foo;
private double _bar;
private double _baz;

// Properties
public double Foo
{
    get{ return _foo; }
    set{ _foo = value; }
}

public double Bar
{
    get{ return _bar; }
    set{ _bar = value; }
}

public double Baz
{
    get{ return _baz; }
}

내부 개인 속성 없이 이러한 속성을 다시 작성할 수 있다는 것을 알고 있습니다.

public double Foo{ get; set; }
public double Bar{ get; set; }
public double Baz{ get; private set; }

이것에 대한 입력을 원합니다.

• 더 새롭고 간결한 스타일보다 더 오래되고 더 명시적인 스타일을 선호 할만한 이유가 있습니까?
• 간결한 스타일을 사용하여 새 클래스를 작성해야합니까, 일관성을 위해 이전 코드와 일치시켜야합니까? 이 경우 일관성이 이전 형식을 정당화하기에 충분합니까?

소위 "이전"스타일이 여전히 필요한 경우가 몇 가지 있습니다.

A : 언어 제공 불변성을 사용하는 불변 유형. readonlyC # 의 수정자는 생성 후 해당 값을 고정시킵니다. 자동 구현 속성 (아직)으로이를 모방 할 방법은 없습니다.

public sealed class FooBarBazInator
{
    private readonly double foo;

    public FooBarBazInator(double foo)
    {
        this.foo = foo;
    }

    public double Foo
    {
        get
        {
            return this.foo;
        }
    }
}

B : 게터 / 세터는 어떤 논리도 가지고 있습니다. 클래스에 데이터 바인딩 된 WPF 및 Silverlight (및 유사한) 코드는 다음 INotifyPropertyChanged과 같이 구현됩니다 .

public class FooBarBazInator : INotifyPropertyChanged
{
    private double foo;

    public event PropertyChangedEventHandler PropertyChanged;

    public double Foo
    {
        get
        {
            return this.foo;
        }

        set
        {
            this.foo = value;
            this.RaisePropertyChanged("Foo");
        }
    }

    private void RaisePropertyChanged(string propertyName)
    {
        var propertyChanged = this.PropertyChanged;

        if (propertyChanged != null)
        {
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

그 외에는 새로운 스타일을 사용한다고 말하고 싶습니다. 코드를 간결하게 유지하고 버그가 발생할 수있는 노출 영역을 줄입니다. 또한 로직을 포함하도록 변경해야하는 경우 서명이 호환되지 않습니다.

명시적인 백업 필드를 갖는 것은 쓸모없는 헛소리라고 말합니다. 코드를 더 길고 읽기 어렵게 만듭니다. 또한 오류 가능성을 추가합니다.

public double Bar
{
    get { return _baz; }
    set { _bar = value; }
}

나는 이런 오류가 아주 쉽게 일어날 수 있고 발견하기가 어렵다고 생각합니다.

일관성을 원한다면 다른 방법으로 수행하십시오. 백업 필드를 사용하는 코드를 자동 속성을 사용하는 코드로 변경하십시오. ReSharper와 같은 리팩토링 도구를 사용하는 경우 특히 쉽습니다 (그렇지 않은 것을 사용하지 않으면 시작해야한다고 생각합니다).

물론, 지원 분야가 필요한 경우가 여전히 있지만이 질문과 관련이 없다고 생각합니다.

질문이 꽤 오래되었지만 여기에 언급 할 가치가있는 책에서 읽은 몇 가지 요점을 추가하는 것을 생각했습니다.

1. 런타임 직렬화 엔진은 직렬화 된 스트림에 파일 이름을 유지합니다. AIP (자동 구현 속성)의 지원 필드 이름은 컴파일러에 의해 결정되며 실제로 코드를 다시 컴파일 할 때마다이 지원 필드의 이름을 변경할 수 있습니다. AIP. 따라서 직렬화 또는 역 직렬화하려는 모든 유형의 AIP를 사용하지 마십시오.

2. 디버깅 할 때 AIP get 또는 set 메소드에 중단 점을 둘 수 없으므로 애플리케이션이이 특성을 가져 오거나 설정하는시기를 쉽게 감지 할 수 없습니다. 수동으로 구현 된 중단 점에 중단 점을 설정할 수 있습니다

더 새롭고 간결한 스타일보다 더 오래되고 더 명시적인 스타일을 선호 할만한 이유가 있습니까?

실제로는 아닙니다. 비록 당신이 그와 같은 재산을 통과 할 때마다, 당신은 처음에 공공 장소를 사용 했어야한다고 주장 할 것입니다.

간결한 스타일을 사용하여 새 클래스를 작성해야합니까, 일관성을 위해 이전 코드와 일치시켜야합니까? 이 경우 일관성이 이전 형식을 정당화하기에 충분합니까?

위의 조언을 무시하고 통과 속성이 있다고 가정하면 스타일과 일치하는 것을 목표로하지 않습니다. 이상적으로는 이전 스타일을 새로운 스타일로 리팩토링하여 일관성을 유지하지만 사람들이 해당 코드를 잘못 읽을 가능성은 적습니다.