답변.

문제의 역사:

Record 클래스(record)는 Java 14에서 미리 보기로 등장하였고, Java 16부터는 안정적인 기능으로 제공됩니다. 이것은 데이터 저장을 위한 변하지 않는(immutable) 컨테이너 개념을 구현하며, value-object와 유사합니다. 이는 Java의 전통적인 DTO와 POJO의 장황함에 대한 반응입니다.

문제점:

단순한 데이터 객체의 경우, 생성자, equals(), hashCode(), toString()을 수동으로 구현해야 했습니다. 이것은 반복적이며 오류에 취약한 작업으로, 많은 코드 줄을 차지합니다.

해결책:

Record 클래스는 한 줄로 선언되며 자동으로 생성자, getter, equals(), hashCode(), toString()을 얻습니다. Record의 필드는 변하지 않으며(final), 레코드는 특히 애플리케이션의 계층 간 정보 전달에 유용합니다.

코드 예:

public record Point(int x, int y) {}

Point p = new Point(3, 5);
System.out.println(p.x()); // 3
System.out.println(p); // Point[x=3, y=5]

주요 특징:

불변성: 필드는 final이며, 값은 생성자를 통해서만 설정됩니다.
표준 메소드의 자동 생성.
다른 클래스로부터 상속될 수 없음(Object 제외); 인터페이스를 구현할 수 있습니다.

함정 질문.

생성 후 record 객체의 상태를 변경할 수 있나요?

아니요 — 모든 필드는 final이므로 어떤 방법으로도 값을 변경할 수 없습니다.

생성자에서 비표준 로직을 가진 record를 생성할 수 있나요?

네, 간결한 또는 일반 생성자를 정의하고 검사를 추가할 수 있습니다:

public record Point(int x, int y) {
    public Point {
        if (x < 0 || y < 0) throw new IllegalArgumentException();
    }
}

record가 추상적일 수 있거나 다른 클래스의 필드/로직을 상속받을 수 있나요?

아니요 — record는 항상 final입니다. 인터페이스는 구현할 수 있지만, Object를 제외한 클래스는 상속할 수 없습니다.

일반적인 오류 및 안티 패턴

필드를 변경 가능하도록 하려는 시도 — 문법으로 불가능합니다.
record 내에서 복잡한 로직을 만들어 데이터 "컨테이너"의 개념을 위반하는 것.
일반적인 동작이 필요한 경우에 record를 사용하는 것.

실제 사례

부정적인 케이스

각 요청/응답을 위해 긴 POJO를 사용하는 경우, equals, hashCode, toString, 생성자 및 getter를 수동으로 작성해야 함.

장점:

완전한 구현 유연성.

단점:

코드가 많음.
오류를 발생시킬 위험이 높음.

긍정적인 케이스

모든 DTO를 record 클래스로 변환:

public record UserDTO(String login, String email) {}