Record Class 도입기

들어가기

프로젝트 팀원분께서 DTO클래스에 Record를 사용해보는게 어떻겠냐고 하셔서

 

바로 Record 클래스에대해 알아보기 시작했고, 과연 데이터를 실어 나르는데 적합한지 알아봤다.

 

Record Class

JDK 14에서 미리보기형태로 등장한 Record 클래스는 JDK 16에 정식 스펙으로 등록됐다.

 

1. Final Class로 상속이 불가능하다.

2. 불변객체이다 -> 모든 필드가 private final로 정의된다.

3. 중복되는 코드들[Getter, Setter, HashCode, Equals 등] 컴파일 타임에 자동으로 생성된다.

 

한 마디로 코드가 깔끔해진다.

public record UserSignUpRequest(
        @Size(min = 5, message = "아이디는 5자 이상이여야 합니다.")
        @NotBlank(message = "로그인 아이디는 필수 입력입니다.")
        String loginId,
        @Size(min = 8, message = "비밀번호는 8자 이상이여야 합니다.")
        @NotBlank(message = "비밀번호는 필수 입력입니다.")
        String password,
        @NotBlank(message = "닉네임은 필수 입력입니다.")
        String nickname){}

 

이번엔 레코드 클래스를 만들어낸 장본인이 쓴 글을 통해서 도대체 record class가 등장한 목적이 무엇인지 어떤 경우에 사용해야하는지 또 어떤 경우엔 사용해서는 안되는지 궁금했다.

 

자바 공식 레퍼런스를 참조해 알아볼 수 있었다.

 

 

 

 

요약을 보면 불변 데이터의 케리어라고 하고 있고, 이름을 가진 튜플이라고 소개하고있다.

 

 

간단히 발번역을 해보자면...

 

• 간단한 값들의 집합체를 표현하기 위해
• 개발자들이 외적인 행동(여러 보일러플레이트 코드 작성을 의미하는 듯 하다) 불변 데이터 모델링에 집중을 돕기위해 
• 자동 생성되는 데이터 중심 메서드들을 구현
• 이름으로 타입을 식별하고 이주 호환성(?)과 같은 오래된 자바 규칙을 지키기 위해서

마지막은 번역기를 돌려도 뜻을 잘 이해하기 어려웠지만 

 

목표들이 뚜렷하게 나타내는 것은 개발자가 불변 객체(값 전달을 위한)를 쉽고 편리하게 만들기 위해 고안된 것이다.

 

DTO로 사용하기 아주 적합한 클래스라 생각한다.

 

추가로 Non Goal도 살펴보면

 

 

첫 번째 단락에서 말하는 것은 레코드가 보일러 플레이트를 없애 주는 효율성을 제공하기는 하지만! 이것이 모든 자바빈 규칙(Get,Set과 같은 규칙)을 무시하고 전쟁을 선언하겠다는 것은 아니다!

 

즉 일반적인 자바클래스에게 도전장을 내밀고 "너 비효율적이야"라고 시비거는 것이 아니라

 

단순히 데이터 전달을 위한 불변 객체 용도로 고안됐다는 의미인것 같다.

 

정말 불변일까?

공식 사이트에서 불변이라는데 토를 달 생각은 없지만

 

곰곰히 생각해보면 final은 사실 불변성을 보장하는 것이 아닌 재할당을 불가능하게 하는 키워드다.

 

그게 그거 같지만 불변성을 기대하고 섣부르게 자료구조를 선택해서는 안된다.

 

public record User(String firstName, String lastName, List<String> emailAddress) {
}

 

위 레코드 클래스 변수에 emailAddress라는 List자료구조는 절대 재할당은 불가능하다.

 

하지만 기존 List 인스턴스에 요소를 추가한다면 그대로 추가된다.

emailAddress.add("john@doe.com");
emailAddress.add("john02@test.com");

 

이런 점을 인지한 뒤에 적절하게 활용한다면 우린 불변객체를 만들어 낼 수 있다.

결론

쓰자!

 

-참고

 

JEP 395: Records