C # 3.0 자동 속성 — 유용합니까? [닫은]

참고 : 이것은 C #을 시작할 때 게시되었습니다. 2014 년 지식을 바탕으로 자동 속성은 C # 언어에서 일어난 최고의 일 중 하나라고 진정으로 말할 수 있습니다.

개인 및 공용 필드를 사용하여 C #에서 속성을 만드는 데 익숙합니다.

private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

이제 .NET 3.0에서는 자동 속성이 생겼습니다.

public string Title { get; set; }

나는 이것이 철학적 / 주관적인 질문이라는 것을 알고 있지만 각 필드에 대해 5 줄의 코드를 저장하는 것 외에는 이러한 자동 속성을 사용하는 이유가 있습니까? 내 개인적인 불만은 그 속성이 내게 물건을 숨기고 있고 나는 흑 마법의 열렬한 팬이 아니라는 것입니다.

실제로 숨겨진 private 필드는 디버거에 표시되지도 않습니다. get / set 함수가 아무 작업도하지 않는다는 사실을 감안하면 괜찮습니다. 그러나 실제로 getter / setter 로직을 구현하려면 어쨌든 private / public 쌍을 사용해야합니다.

나중에 getter / setter 논리를 변경할 수있는 기능을 잃지 않고 많은 코드 (1 줄 대 6 줄)를 저장하는 이점을 알 수 있습니다. 그러나 다시 한 번, 간단히 public 필드를 "Public string Title"없이 선언하여이를 수행 할 수 있습니다. {get; 세트; } 블록, 따라서 더 많은 코드를 절약 할 수 있습니다.

그래서 내가 여기서 무엇을 놓치고 있습니까? 왜 누군가 실제로 자동 속성을 사용하고 싶습니까?

우리는 Stack Overflow에서 항상 사용합니다.

또한 속성 대 공용 변수 에 대한 토론에 관심이있을 수 있습니다 . IMHO는 이것이 실제로 반응이며 그 목적을 위해 훌륭합니다.

예, 코드 만 저장합니다. 당신이 그것들이 많을 때 읽기가 더 쉽습니다. 더 빨리 작성하고 유지 관리하기 쉽습니다. 코드 저장은 항상 좋은 목표입니다.

다른 범위를 설정할 수 있습니다.

public string PropertyName { get; private set; }

따라서 속성은 클래스 내에서만 변경할 수 있습니다. 리플렉션을 통해 개인 setter에 계속 액세스 할 수 있으므로 실제로 변경 불가능한 것은 아닙니다.

C # 6부터 진정한 readonly속성, 즉 생성자 외부에서 변경할 수없는 불변 속성을 만들 수도 있습니다 .

public string PropertyName { get; }

public MyClass() { this.PropertyName = "whatever"; }

컴파일 시간에 다음과 같이됩니다.

readonly string pName;
public string PropertyName { get { return this.pName; } }

public MyClass() { this.pName = "whatever"; }

멤버가 많은 불변 클래스에서 이것은 많은 초과 코드를 절약합니다.

속성 대신 필드를 사용할 때의 세 가지 큰 단점은 다음과 같습니다.

1. 필드에는 데이터 바인딩 할 수 없지만 속성에는 할 수 있습니다.
2. 필드를 사용하여 시작하면 나중에 (쉽게) 속성으로 변경할 수 없습니다.
3. 필드에 추가 할 수없는 속성에 추가 할 수있는 몇 가지 특성이 있습니다.

저는 개인적으로 자동 속성을 좋아합니다. 코드 줄을 저장하는 데있어 문제점은 무엇입니까? getter 또는 setter에서 작업을 수행하려는 경우 나중에 일반 속성으로 변환하는 데 문제가 없습니다.

말했듯이 필드를 사용할 수 있으며 나중에 논리를 추가하려면 속성으로 변환해야합니다. 그러나 이것은 반사를 사용하는 데 문제가 될 수 있습니다.

또한 속성을 사용하면 필드로 수행 할 수없는 getter 및 setter에 대해 다른 액세스 수준을 설정할 수 있습니다.

var 키워드와 동일하다고 생각합니다. 개인적인 취향의 문제입니다.

C ++를 만든 Bjarne Stroustrup에서 :

특히 get 및 set 함수가 많은 클래스를 싫어합니다. 이것은 종종 처음에 수업이 아니어야한다는 표시입니다. 데이터 구조 일뿐입니다. 그리고 그것이 정말로 데이터 구조라면 데이터 구조로 만드십시오.

그리고 그거 알아? 그가 맞아. 단순히 "객체 지향"작업이기 때문에 get / set 내에서 실제로 아무것도하지 않고 단순히 get 및 set에서 private 필드를 래핑하는 빈도입니다. 이것은 문제에 대한 Microsoft의 솔루션입니다. 기본적으로 바인딩 할 수있는 공개 필드입니다.

아무도 언급하지 않은 것으로 보이는 한 가지는 불행히도 자동 속성이 불변 객체 (일반적으로 불변 구조체)에 유용하지 않다는 것입니다. 이를 위해 정말로해야 할 일 :

private readonly string title;
public string Title
{
    get { return this.title; }
}

(여기서 필드는 전달 된 매개 변수를 통해 생성자에서 초기화 된 다음 읽기 전용입니다.)

따라서 이것은 단순 get/ 자동 private set속성에 비해 장점이 있습니다 .

인터페이스 정의에서 속성을 사용할 수 있기 때문에 항상 공용 필드 대신 속성을 만듭니다. 인터페이스 정의에서는 공용 필드를 사용할 수 없습니다.

자동 속성은 C #의 다른 어떤 것만큼이나 마술입니다. 일단 일반적인 C # 속성으로 확장하는 것이 아니라 IL로 컴파일하는 관점에서 생각해 보면 다른 많은 언어 구조보다 훨씬 덜 마술입니다.

나는 항상 자동 속성을 사용합니다. C # 3 이전에는 모든 입력에 신경을 쓸 수 없었고 대신 공용 변수를 사용했습니다.

내가 놓친 유일한 것은 이것을 할 수 있다는 것입니다.

public string Name = "DefaultName";

속성이있는 생성자로 기본값을 이동해야합니다. 지루한 :-(

직관적이고 코드 줄을 줄이는 구조는 큰 장점이라고 생각합니다.

이러한 기능은 Ruby와 같은 언어를 강력하게 만드는 요소입니다 (과잉 코드를 줄이는데도 도움이되는 동적 기능).

Ruby는이 모든 것을 다음과 같이 가지고 있습니다.

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

내가 가진 유일한 문제는 그들이 충분히 멀리 가지 않는다는 것입니다. 자동 속성을 추가 한 컴파일러의 동일한 릴리스에 부분 메서드가 추가되었습니다. 그들이 두 가지를 합치 지 않은 이유는 나를 넘어선 다. 단순한 "부분적 On <PropertyName> Changed"는 이러한 것들을 정말 유용하게 만들었습니다.

간단하고 짧으며, 속성의 본문 어딘가에 실제 구현을 생성하려는 경우 유형의 외부 인터페이스가 손상되지 않습니다.

저것과 같이 쉬운.

여기서 주목해야 할 점은 제가 이해하기로 이것은 C # 3.0 쪽의 구문 설탕 일 뿐이며 컴파일러에 의해 생성 된 IL이 동일하다는 것을 의미합니다. 나는 흑 마법을 피하는 것에 동의하지만, 같은 일에 대해 똑같이 적은 줄을 쓰는 것이 일반적으로 좋은 일입니다.

제 생각에는 항상 공개 필드 대신 자동 속성을 사용해야합니다. 즉, 여기에 타협이 있습니다.

속성에 사용할 명명 규칙을 사용하여 내부 필드로 시작 합니다. 당신이 처음으로

• 어셈블리 외부에서 필드에 액세스해야합니다.
• getter / setter에 로직을 첨부해야합니다.

이 작업을 수행:

1. 필드 이름 변경
2. 비공개로
3. 공공 재산 추가

클라이언트 코드는 변경할 필요가 없습니다.

하지만 언젠가는 시스템이 성장하고이를 별도의 어셈블리와 여러 솔루션으로 분해 할 것입니다. 이런 일이 발생하면 Jeff가 언급했듯이 공개 필드를 공개 속성으로 변경하는 것은 API 변경 사항을 깨는 것이기 때문에 노출 된 모든 필드가 다시 나타나게됩니다 .

CodeRush를 사용하는데 자동 속성보다 빠릅니다.

이것을하기 위해:

 private string title;
public string Title
{
    get { return title;  }
    set { title = value;  }
}

총 8 번의 키 입력이 필요합니다.

코드 스 니펫을 사용하면 동일한 이름의 자동 속성은 총 7 번의 키 입력이됩니다.)

@Domenic : 모르겠어요 .. 자동 속성으로이 작업을 수행 할 수 없습니까? :

public string Title { get; }

또는

public string Title { get; private set; }

이것이 당신이 말하는 것입니까?

자동 속성에 대한 나의 가장 큰 불만은 시간을 절약하도록 설계되었다는 것입니다.하지만 나중에 완전한 속성으로 확장해야하는 경우가 많습니다.

VS2008에서 누락 된 것은 Explode Auto-Property 리 팩터입니다.

캡슐화 필드 리팩터링 이 있다는 사실은 공용 필드를 사용하기 위해 더 빠르게 작업하는 방식을 만듭니다.