Microsoft MVP성태의 닷넷 이야기
닷넷: 2295. C# 12 - 기본 생성자(Primary constructors) (책 오타 수정) [링크 복사], [링크+제목 복사],
조회: 6771
글쓴 사람
정성태 (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# 컴파일러가 친절하게 경고까지 내주니 현실적으로 클래스의 크기가 달라질 일은 없을 듯합니다. ^^ (본문에서, 그 부분을 취소 처리했습니다.)
정성태

... 46  47  48  49  50  51  52  53  54  55  [56]  57  58  59  60  ...
NoWriterDateCnt.TitleFile(s)
12535정성태2/9/202117252개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/202117763개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/202116777개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/202117972개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/202116758개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202120564개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202118447개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/202118000개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/202118098개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/202114893개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
12525정성태2/1/202113878개발 환경 구성: 531. Azure Devops - 파이프라인 실행 시 빌드 이벤트를 생략하는 방법
12524정성태1/31/202115097개발 환경 구성: 530. 기존 github 프로젝트를 Azure Devops의 빌드 Pipeline에 연결하는 방법 [1]
12523정성태1/31/202115986개발 환경 구성: 529. 기존 github 프로젝트를 Azure Devops의 Board에 연결하는 방법
12522정성태1/31/202118195개발 환경 구성: 528. 오라클 클라우드의 리눅스 VM - 9000 MTU Jumbo Frame 테스트
12521정성태1/31/202117307개발 환경 구성: 527. 이더넷(Ethernet) 환경의 TCP 통신에서 MSS(Maximum Segment Size) 확인 [1]
12520정성태1/30/202116066개발 환경 구성: 526. 오라클 클라우드의 VM에 ping ICMP 여는 방법
12519정성태1/30/202114768개발 환경 구성: 525. 오라클 클라우드의 VM을 외부에서 접근하기 위해 포트 여는 방법
12518정성태1/30/202132885Linux: 37. Ubuntu에 Wireshark 설치 [2]
12517정성태1/30/202120587Linux: 36. 윈도우 클라이언트에서 X2Go를 이용한 원격 리눅스의 GUI 접속 - 우분투 20.04
12516정성태1/29/202117057Windows: 188. Windows - TCP default template 설정 방법
12515정성태1/28/202118711웹: 41. Microsoft Edge - localhost에 대해 http 접근 시 무조건 https로 바뀌는 문제 [3]
12514정성태1/28/202118847.NET Framework: 1021. C# - 일렉트론 닷넷(Electron.NET) 소개 [1]파일 다운로드1
12513정성태1/28/202116020오류 유형: 698. electronize - User Profile 디렉터리에 공백 문자가 있는 경우 빌드가 실패하는 문제 [1]
12512정성태1/28/202116398오류 유형: 697. The program can't start because VCRUNTIME140.dll is missing from your computer. Try reinstalling the program to fix this problem.
12511정성태1/27/202116107Windows: 187. Windows - 도스 시절의 8.3 경로를 알아내는 방법
12510정성태1/27/202116965.NET Framework: 1020. .NET Core Kestrel 호스팅 - Razor 지원 추가 [1]파일 다운로드1
... 46  47  48  49  50  51  52  53  54  55  [56]  57  58  59  60  ...