C # 3.0 자동 속성 – 유용합니까?

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 줄의 코드를 저장하는 것을 제외하고 이러한 자동 속성을 사용해야 할 이유가 있습니까? 내 개인적인 그립은 그 속성이 나에게서 물건을 숨기고 있다는 것이며, 나는 흑 마법의 큰 팬이 아닙니다.

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

나중에 getter / setter 논리를 변경하는 기능을 잃지 않고 많은 코드 (1 대 6 줄)를 저장한다는 이점을 보았습니다.하지만 다시 공개 필드 "Public string Title"을 선언하지 않고 이미 그렇게 할 수 있습니다 {get; 세트; } 블록을 통해 더 많은 코드를 저장합니다.

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

---

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

Properties vs. Public Variables 에 대한 토론에 관심이있을 수도 있습니다 . IMHO 그것이 실제로 이것이 반응에 해당하는 것이며, 그 목적을 위해서는 위대합니다.

---

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

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

public string PropertyName { get; private set; }

따라서 속성은 클래스 내에서만 변경할 수 있습니다. 리플렉션을 통해 여전히 개인 세터에 액세스 할 수 있으므로 이것은 불변이 아닙니다.

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에서 작업을 수행하려는 경우 나중에 일반 속성으로 변환하는 데 아무런 문제가 없습니다.

당신이 말했듯이 필드를 사용할 수 있고 나중에 논리를 추가하려면 속성으로 변환합니다. 그러나 이것은 반사 (및 다른 곳에서)를 사용할 때 문제가 될 수 있습니다.

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

나는 그것이 var 키워드와 같은 것 같아요. 개인적인 취향의 문제.

---

C ++ 제작자 인 Bjarne Stroustrup에서 :

특히 get 및 set 함수가 많은 클래스를 싫어합니다. 그것은 종종 그것이 처음에는 수업이 아니어야 함을 나타냅니다. 데이터 구조 일뿐입니다. 실제로 데이터 구조 인 경우 데이터 구조로 만듭니다.

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

---

아무도 언급하지 않은 것 중 하나는 불행히도 자동 속성이 불변 개체 (보통 불변 구조체)에 유용하지 않은 방법입니다. 그 때문에 당신은 정말로해야합니다 :

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

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

따라서 이것은 간단한 get/ 자동 private set속성 보다 장점이 있습니다 .

---

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

---

자동 속성은 C #의 다른 것만큼이나 마술입니다. 일단 일반적인 C # 속성으로 확장되지 않고 IL로 컴파일하는 관점에서 생각하면 다른 많은 언어 구성보다 블랙 매직이 훨씬 적습니다.

---

I use auto-properties all the time. Before C#3 I couldn't be bothered with all the typing and just used public variables instead.

The only thing I miss is being able to do this:

public string Name = "DefaultName";

You have to shift the defaults into your constructors with properties. tedious :-(

---

I think any construct that is intuitive AND reduces the lines of code is a big plus.

Those kinds of features are what makes languages like Ruby so powerful (that and dynamic features, which also help reduce excess code).

Ruby has had this all along as:

attr_accessor :my_property
attr_reader :my_getter
attr_writer :my_setter

---

The only problem I have with them is that they don't go far enough. The same release of the compiler that added automatic properties, added partial methods. Why they didnt put the two together is beyond me. A simple "partial On<PropertyName>Changed" would have made these things really really useful.

---

It's simple, it's short and if you want to create a real implementation inside the property's body somewhere down the line, it won't break your type's external interface.

As simple as that.

---

One thing to note here is that, to my understanding, this is just syntactic sugar on the C# 3.0 end, meaning that the IL generated by the compiler is the same. I agree about avoiding black magic, but all the same, fewer lines for the same thing is usually a good thing.

---

In my opinion, you should always use auto-properties instead of public fields. That said, here's a compromise:

Start off with an internal field using the naming convention you'd use for a property. When you first either

• need access to the field from outside its assembly, or
• need to attach logic to a getter/setter

Do this:

1. rename the field
2. make it private
3. add a public property

Your client code won't need to change.

Someday, though, your system will grow and you'll decompose it into separate assemblies and multiple solutions. When that happens, any exposed fields will come back to haunt you because, as Jeff mentioned, changing a public field to a public property is a breaking API change.

---

I use CodeRush, it's faster than auto-properties.

To do this:

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

Requires eight keystrokes total.

---

Well with code snippets an auto-property of the same name would be seven keystrokes in total ;)

---

@Domenic : I don't get it.. can't you do this with auto-properties?:

public string Title { get; }

or

public string Title { get; private set; }

Is this what you are referring to?

---

My biggest gripe with auto-properties is that they are designed to save time but I often find I have to expand them into full blown properties later.

What VS2008 is missing is an Explode Auto-Property refactor.

The fact we have an encapsulate field refactor makes the way I work quicker to just use public fields.

참고URL : https://stackoverflow.com/questions/9304/c-sharp-3-0-auto-properties-useful-or-not