새로운 필드 키워드가 C# 속성을 개선하는 방법

Overview of C# Properties and the Upgrade in C# 14

Tim은 C# 14에서 C# 속성에 큰 업그레이드가 있음을 설명하며 시작합니다. 그는 비디오의 초점이 자동 속성이 내부적으로 작동하는 방식에 영향을 미치는 새로운 필드 키워드에 있음을 분명히 합니다. Tim은 또한 C# 14가 .NET 10 및 Visual Studio 2026과 함께 출하되지만, 해당 기능 자체는 이전 .NET 버전에서도 작동할 수 있다고 언급합니다.

그는 이 동영상을 빠르고 집중된 설명으로 구성하여 한 가지 특정 질문, 즉 실제 코드에서 이 새로운 기능을 어떻게 사용하나요? 라는 질문에 답변하는 데 중점을 두었습니다. 이는 속성 정의에 대한 이론적 논의보다는 실질적인 실습을 위한 안내의 톤을 설정합니다.

사람 클래스 예제 및 자동 속성

약 0:23에, 팀은 간단한 public class Person을 포함한 콘솔 애플리케이션을 소개합니다. 이 사람 클래스에는 여러 개의 공개 속성이 포함되어 있습니다. 다음을 포함하여:

• public string FirstName

public string LastName

• public int Age

팀은 이것들이 자동 구현 속성(자동으로 구현된 속성이라고도 함)이라고 설명합니다. 컴파일러가 자동으로 비공개 필드를 백그라운드에서 생성하기 때문에 보이는 비공개 변수나 비공개 필드는 없습니다.

그는 또한 자동으로 구현되지 않는 Demo 속성을 포함합니다. 대신, 그것은 개인 문자열 백업 필드(_demo)를 사용하고 get 접근자만을 사용하여 읽기 전용 속성을 노출합니다. 이 대조는 나중에 비디오에서 중요해집니다.

Program.cs에서 속성 사용하기

그다음 팀(Tim)은 클래스 Program으로 이동하여 Person 객체가 public static void main (또는 개념적으로 static void main string args) 내부에서 어떻게 생성되는지를 보여줍니다. 그는 다음을 사용하여 새로운 사람을 인스턴스화합니다:

new Person { FirstName = "Tim", LastName = "Corey" }

Tim은 속성을 사용하면 여전히 비공개 데이터 멤버를 숨기면서 클래스 외부에서 접근할 수 있다고 지적합니다. 그는 성, 나이, 데모와 같은 값을 검색하며 프로퍼티가 필드처럼 보이지만 실제로는 뒤에서 특수 메서드라는 것을 보여줍니다.

자동 프로퍼티의 잘못된 값 문제

약 1:23경, 팀이 의도적으로 잘못된 값을 할당합니다:

person.LastName = null;

LastName이 필수이며 nullable로 표시되지 않았지만, 할당은 런타임에서 여전히 작동합니다. Tim은 자동 프로퍼티가 잘못된 값을 자동으로 방지하지 않는다고 설명합니다. 컴파일러가 경고를 하지만, set 메서드는 여전히 그 값을 받아들입니다.

이것은 자동 구현 속성의 주요 문제를 보여줍니다: 간결하지만, 유효성 검사를 추가할 수 있는 내장된 방법을 제공하지 않습니다. 유효하지 않은 데이터는 통과하여 조용히 가정을 깨뜨릴 수 있습니다.

백업 필드가 있는 전통적인 전체 속성

약 2:58경에 팀은 이전 버전의 C#에서 개발자들이 했던 일을 보여줍니다. 그는 LastName을 완전 구현된 속성으로 변환합니다:

• 개인 문자열 백업 필드

속성 값을 확인하는 설정 접근자

잘못된 값에 대한 예외 발생

이 접근 방식은 속성 접근자에 대한 완전한 제어를 제공하지만, Tim은 얼마나 장황해지는지를 강조합니다. 이제 속성은 자동 속성의 단일 행 구문과 비교하여 여러 줄을 차지합니다.

그는 자동 속성에서 전체 속성으로 전환해도 기존 코드를 깨뜨리지 않음을 설명합니다. 속성 이름, 접근 수준 및 외부 사용이 동일하게 유지되기 때문입니다.

중간 지대로서의 New 필드 키워드

4:19에 Tim은 C# 14의 주요 개선점을 소개합니다. 전체 속성을 작성하는 대신, 자동 속성 구조를 유지하면서 set 접근자만 필드 키워드를 사용하여 수정합니다.

Tim은 필드가 일반적으로 숨겨진 채로 유지되는 컴파일러 생성 private 필드를 나타낸다고 설명합니다. 필드에 값을 할당하여 개발자는 자신의 private 변수를 선언하지 않고도 속성 값을 가로채고 검증할 수 있습니다.

이는 개발자가 익숙한 구문을 유지하면서도 유연성을 추가합니다. Tim은 이것이 코드 양을 줄이면서도 검증 논리를 허용하고, 자동 속성과 전체 속성 사이에 위치시킨다고 강조합니다.

Scoped Backing Fields 및 속성 고립화

Tim은 필드 키워드가 나타나는 속성에 스코프가 지정됨을 설명합니다. 각 속성이 자신의 백업 필드를 얻으며, 속성 간 간섭의 위험이 없습니다.

다른 속성(예: FirstName)에서 동일한 구문을 사용할 경우, 해당 속성의 백업 필드를 참조합니다. 이는 여러 공용 속성에 걸쳐 기능을 예측 가능하고 안전하게 사용하게 만듭니다.

나이와 같은 숫자 속성 검증하기

6:16 경에 Tim은 동일한 접근 방식을 공용 int Age 속성에 적용합니다. 그는 유효하지 않은 음수 값을 할당하고, 그것이 허용되어서는 안 되는 이유를 설명합니다.

예외를 던지는 대신에, Tim은 다른 전략을 보여줍니다: 유효하지 않은 값을 무시하기. set 메서드는 필드에 값을 할당하기 전에 값이 유효한 범위 내에 있는지 확인합니다.

이는 새로운 접근 방식이 private int age, 숫자 검증 및 조건 논리를 위한 속성으로서 전체 구현으로 변환하지 않고도 동일하게 잘 작동함을 보여줍니다.

필드 키워드와의 명명 충돌

Tim은 잠재적인 극단적인 경우인 명명 충돌에 대해 논의합니다. 클래스에 이미 field라는 변수가 있으면, 속성 내부에서 새로운 키워드와 충돌할 수 있습니다.

그는 이것이 혼란 및 예기치 못한 동작을 초래하는 것을 보여줍니다. Tim은 해결책이 this.field 또는 @field를 사용하여 변수를 명시적으로 참조하는 것임을 설명합니다. 이로 인해 변수 이름과 백업 필드 키워드를 구분할 수 있습니다.

Tim은 특히 기존 코드베이스를 업그레이드할 때 이러한 변수를 새 이름으로 바꾸는 것이 좋은 관행이라고 강력히 권장합니다.

명명 충돌이 적용되지 않는 경우

Tim은 필드 키워드가 속성 접근자 내부에서만 특별한 의미를 갖는다고 명확히 합니다. 생성자, 메서드 또는 클래스의 다른 부분에서는 필드가 일반 변수처럼 동작합니다.

이 차별은 개발자가 컴파일러 생성 백업 필드가 존재하는지 여부를 이해하게 합니다.

Tim Corey의 최종 생각

Tim은 그의 비디오를 마무리하며 새로운 필드 키워드가 어떻게 작용하는지, 그리고 C#의 속성을 어떻게 개선하는지를 요약합니다. 이를 통해 개발자가 자동 속성을 계속 사용할 수 있으면서도 검증, 제어 및 명확성을 추가할 수 있습니다.

그는 시청자들에게 이 기능을 시도해보고, 그들의 코딩 스타일에 어떻게 맞는지 탐구하며, 명명 규칙에 대해 신중히 생각해 보기를 권장합니다. Tim은 필요 없는 복잡성을 추가하지 않고 속성을 더 표현력 있게 만든다는 점을 강조하면서 비디오를 마칩니다.