Microsoft MVP성태의 닷넷 이야기
닷넷: 2295. C# 12 - 기본 생성자(Primary constructors) (책 오타 수정) [링크 복사], [링크+제목 복사],
조회: 6865
글쓴 사람
정성태 (seongtaejeong at gmail.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

C# 12 - 기본 생성자(Primary constructors) (책 오타 수정)

"영귤" 님의 피드백으로 알게 되었습니다. 문제는, 내용을 단순히 몇 글자 수정하는 것으로 끝내려니 문맥이 좀 이상해져서 조금 많이 수정한 다음 이렇게 공개 글로 남깁니다. (이 내용은 향후 개정판이 나온다면 반영될 것입니다.)

참고로, 몇년 전부터는 글로 옮기기 전에 먼저 이렇게 정리해 두었는데,

C# 12 - 기본 생성자(Primary Constructors)
; https://www.sysnet.pe.kr/2/0/13339

오히려 저 글이 더 preview 내용을 바탕으로 쓴 것임에도 불구하고 정정할 내용이 없군요. ^^;




생성자 메서드는 인스턴스의 초기화 외에도 기타 관련 코드를 포함할 수도 있겠지만 경우에 따라서는 아래의 코드처럼 단순히 내부 상태를 설정하는 용도로만 정의할 때도 많다.

PersonDTO p = new PersonDTO("John", 42);

public class PersonDTO
{
    // 내부 멤버를 초기화하는 코드만 포함하는 생성자 메서드
    public PersonDTO(string name, int age)
    {
        Name = name;
        Age = age;
    }
    public string Name { get; set; }
    public int Age { get; set; }
}

자칫 반복적일 수 있는 이런 식의 코드는 C# 9부터 나온 record 문법을 활용하면 단 1줄의 코드로 줄이는 것이 가능하다.

public record class PersonDTO(string Name, int Age);
// 또는 public record struct PersonDTO(string Name, int Age);

이처럼 편리한 record의 생성자 메서드 정의 방식을 C# 12부터 일반 타입에 도입한 것이 바로 기본 생성자 (Primary constructor)다.

public class PersonDTO(string name, int age); // 기본 생성자를 정의하는 신규 문법

// 또는 public struct PersonDTO(string name, int age);

단지 record와는 다르게 기본 생성자의 매개변수가 항상 내부 필드로 구현되지는 않는다. 예를 들어 아래와 같이 기본 생성자를 자동 구현 속성과 연동하면,

// 기본 생성자의 매개변수를 자동 구현 속성에서 사용하는 예제
public class PersonDTO(string name, int age)
{
    public string Name { get; private set; } = name;
    public int Age { get; private set; } = age;
}

내부적으로 이렇게 바뀌어서 컴파일된다.

// C# 컴파일러에 의해 자동 작성된 기본 생성자
public class PersonDTO
{
    public PersonDTO(string name, int age) // 확장된 기본 생성자
    {
        this.Name = name;
        this.Age = age;
    }
    public string Name { get; private set; }
    public int Age { get; private set; }
}

반면 대응하는 속성이나 필드 없이 직접 멤버 메서드에서 사용하는 경우에는,

// 기본 생성자의 매개변수를 멤버 메서드에서 직접 사용하는 예제
public class PersonDTO(string name, int age)
{
    public override string ToString() => $"{name}: {age}";
}

내부적으로 필드를 자동으로 생성한 다음 생성자를 통해 초기화 코드를 연결하고 ToString 메서드에서 사용하도록 확장한다.

// C# 컴파일러에 의해 자동 작성된 기본 생성자
public class PersonDTO
{
    string _name; // 필드로 확장된 매개변수 (실제 필드 이름은 이와 다름)
    int _age;

    public PersonDTO(string name, int age) // 확장된 기본 생성자
    {
        _name = name;
        _age = age;
    }

    public override string ToString() => $"{_name}: {_age}";
}

따라서, 매개변수와는 별도로 내부에서 어떻게 연동했느냐에 따라 클래스의 크기가 달라진다.

마지막으로 기본 생성자를 사용할 때 유의할 점이 있다면 다른 생성자를 함께 정의하는 경우 반드시 기본 생성자를 경유하는 this 호출 코드를 넣어야 한다는 점이다. 다음 예제는 name만을 받는 생성자를 별도로 정의하면서 기본 생성자 측으로 this 호출을 넘기고 있다.

PersonDTO p = new PersonDTO("John"); // 기본 생성자가 아닌 사용자가 만든 생성자 호출

public struct PersonDTO(string name, int age)
{
    public PersonDTO(string name) : this(name, 0) { }

    public string Name = name;
    public int Age { get; init; } = age;
}

정리하자면, 개념상 기본 생성자에 지정한 매개변수들을 class/struct 정의 문법 내에서 유효하게 사용할 수 있는 변수라고 볼 수 있다.




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 8/29/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2024-08-29 11시42분
"내부에서 어떻게 연동했느냐에 따라 클래스의 크기가 달라진다."는 말씀이
public class PersonDTO(string name, int age)
{
    public string Name { get; private set; } = name;
    public int Age { get; private set; } = age;
}

public class PersonDTO(string name, int age)
{
    public override string ToString() => $"{name}: {age}";
}
가 크기가 달라진다는 말씀이 아니라

public class PersonDTO(string name, int age)
{
    public override string ToString() => $"{name}: {age}";
}
를 만들면서 필드든 프로퍼티든 생성되지 않을 것처럼 오해하지 말라는 말씀이지요?
그사람
2024-08-29 12시07분
넵, 같은 이야기일 듯합니다. 생성자에서 연동하는 방식이 아니면 숨겨진 필드를 이용해 연동하기 때문에 마찬가지로 클래스의 크기가 달라지는 것입니다.
정성태
2024-08-29 06시07분
퇴근해서 다시 보니, 말씀하신 의도를 이제야 이해했습니다. ^^; 결국 그걸 굳이 언급할 필요가 없었던 것 같습니다. 어떤 식으로든 사용하면 내부 필드로 매칭될 수밖에 없고, 만약 그 2가지 방법 중 어느 하나라도 쓰지 않으면 C# 컴파일러가 친절하게 경고까지 내주니 현실적으로 클래스의 크기가 달라질 일은 없을 듯합니다. ^^ (본문에서, 그 부분을 취소 처리했습니다.)
정성태

... 166  167  168  169  170  171  172  173  174  175  176  177  [178]  179  180  ...
NoWriterDateCnt.TitleFile(s)
535정성태9/11/200729776.NET Framework: 96. WCF - PerSession에서의 클라이언트 연결 관리 [5]
534정성태9/3/200725192개발 환경 구성: 29. VHD 파일 크기 줄이기
533정성태9/2/200727845개발 환경 구성: 28. CA 서비스 - 사용자 정의 템플릿 유형 추가
532정성태9/2/200730450개발 환경 구성: 27. AD CA에서 Code Signing 인증서 유형 추가 방법
531정성태9/2/200726114.NET Framework: 95. WCF에서의 DataTable 사용
530정성태9/1/200722647.NET Framework: 94. WCF 예외에 대한 시행착오
529정성태8/31/200725504.NET Framework: 93. WCF - DataContract와 KnownType 특성 [1]
528정성태8/30/200720170오류 유형: 47. VPC - 네트워크 어댑터 MAC 주소 중복 오류
527정성태8/30/200730272Team Foundation Server: 20. 잠긴 파일을 강제로 해제 [2]
526정성태8/29/200720118오류 유형: 46. VS.NET 2008 - ASP.NET 디버깅 : Strong name validation failed.
525정성태8/27/200722421VS.NET IDE: 54. VS.NET 2008 - 새롭게 도입되는 XSD Schema Designer
524정성태8/23/200739931오류 유형: 45. 요청한 작업은, 사용자가 매핑한 구역이 열려 있는...
523정성태8/16/200722568VS.NET IDE: 53. VS.NET 2008 - 서비스 참조 시 기존 데이터 컨테이너 DLL 사용
522정성태8/13/200726198VS.NET IDE: 52. VS.NET 2008 - WCF를 위한 디버깅 환경 개선
521정성태8/8/200726300.NET Framework: 92. XmlSerializer 생성자의 실행 속도를 올리는 방법 - 두 번째 이야기 [3]
520정성태8/7/200721467VS.NET IDE: 51. Visual Studio 2008 베타 2 설치
519정성태7/27/200727840오류 유형: 44. System.BadImageFormatException [2]
518정성태7/26/200728829오류 유형: 43. System.ComponentModel.LicenseException [1]
517정성태7/19/200717099개발 환경 구성: 26. VPC - 일반 사용자 계정으로 구동
516정성태7/19/200720313오류 유형: 42. TFS - Error loading menu: Index was outside the bounds of the array [2]
515정성태7/18/200727983오류 유형: 41. SSL 서버 자격 증명을 만드는 동안 심각한 오류가 발생했습니다.
514정성태7/14/200720640Team Foundation Server: 19. Orcas에서 개선되는 TFS 기능들
513정성태7/4/200731652.NET Framework: 91. Foreground Thread / Background Thread [1]
512정성태6/27/200721681오류 유형: 40. error PRJ0050: Failed to register output.
511정성태6/25/200729640.NET Framework: 90. XmlSerializer 생성자의 실행 속도를 올리는 방법 [2]
510정성태6/25/200744598디버깅 기술: 15. First-Chance Exception
... 166  167  168  169  170  171  172  173  174  175  176  177  [178]  179  180  ...