필드를 외부 세계에 노출시키는 대신 클래스 필드에 대해 getter 및 setter 메소드 (C #의 특성)를 작성하여 캡슐화를 보호해야한다는 말이 종종 있습니다.
그러나 필드가 값을 보유하기 위해 존재하는 경우가 많으며 얻거나 설정하기 위해 계산이 필요하지 않습니다. 이를 위해 우리는 모두이 숫자를 수행합니다.
public class Book
{
private string _title;
public string Title
{
get{ return _title; }
set{ _title = value; }
}
}
글쎄, 나는 고백을했습니다. 나는 모든 것을 쓸 수 없었습니다.
그런 다음 C # 3.0이 나오고 자동 속성이 추가 된 것을 볼 수 있습니다.
public class Book
{
public string Title {get; set;}
}
어느 것이 더 깔끔하고 고마웠지만 실제로 공공 장소를 만드는 것보다 다른 점은 무엇입니까?
public class Book
{
public string Title;
}
답변
A의 관련 질문 내가 얼마 전에 있었다 약간의 차이를 설명 제프의 블로그에 게시물에 대한 링크가 있었다.
- 리플렉션은 변수와 속성에 따라 다르게 작동하므로 리플렉션에 의존하는 경우 모든 속성을 사용하는 것이 더 쉽습니다.
- 변수에 대해 데이터 바인딩 할 수 없습니다.
-
변수를 속성으로 변경하는 것은 주요 변경 사항입니다. 예를 들면 다음과 같습니다.
TryGetTitle(out book.Title); // requires a variable
답변
API 문제를 무시하면 속성 사용에있어 가장 가치있는 것은 디버깅입니다.
CLR 디버거는 데이터 중단 점을 지원하지 않습니다 (대부분의 기본 디버거는 지원). 따라서 클래스의 특정 필드를 읽거나 쓸 때 중단 점을 설정할 수 없습니다. 이는 특정 디버깅 시나리오에서 매우 제한적입니다.
속성은 매우 얇은 방법으로 구현되므로 값을 읽고 쓸 때 중단 점을 설정할 수 있습니다. 이것은 들판 위에 큰 다리를 제공합니다.
답변
필드에서 속성으로 변경하면 계약이 깨집니다 (예 : 모든 참조 코드를 다시 컴파일해야 함). 따라서 다른 클래스 (공개 (일반적으로 보호되는) 멤버)와의 상호 작용 지점이있는 경우 향후 성장을 계획하려고합니다. 항상 속성을 사용하여 수행하십시오.
오늘날 자동 속성으로 만드는 것은 아무 것도 아닙니다. 3 개월 동안 줄을 서서히로드하고 게터에 널 체크를하고 싶다는 것을 알게되었습니다. 필드를 사용한 경우 어셈블리에 의존하는 사람 및 대상에 따라 최악의 경우 재 컴파일 변경이 가능합니다.
답변
아무도 언급하지 않았기 때문에 : 인터페이스에서 필드를 정의 할 수 없습니다. 따라서 속성을 정의하는 특정 인터페이스를 구현해야하는 경우 자동 속성이 때로는 좋은 기능입니다.
답변
종종 간과되고 다른 답변에서 언급되지 않은 큰 차이 : 재정의 . 속성을 가상으로 선언하고 재정의 할 수 있지만 공용 멤버 필드에 대해서는 동일하게 수행 할 수 없습니다.
답변
버전 관리 및 API 안정성에 관한 모든 것입니다. 버전 1에는 차이가 없습니다. 그러나 나중에 버전 2에서 일부 유형의 오류 검사와 함께이 속성을 속성으로 만들어야한다고 결정하면 API를 변경할 필요가 없습니다. 속성의 정의
답변
공용 필드에 비해 자동 구현 된 속성의 또 다른 장점은 집합 접근자를 개인 또는 보호로 설정하여 공용 필드보다 제어가 잘 정의 된 개체 클래스를 제공 할 수 있다는 것입니다.