해당 포스트는 Meduim 의 아티클 "Java Records: When & Why to use them" 을 번역한 내용이다.
[ 원문 ]
자바 프로그램에서 길고 지루한 코드를 작성하는 것에 피로감을 느낄 수 있다. 다행스럽게도 Java Records 라는 새로운 멋진 기능이 있어 코드를 더 간결하고 가독성 높게 만들어 줄 수 있다.
이 아티클에서는 Java Records 를 사용하는 방법을 보여주고, 작동 방식을 이해하는데 도움이 되는 몇 가지 예제를 제공할 것이다.
또한, 언제 일반 클래스 대신에 Records 를 사용하는게 좋은지에 대해서도 설명하겠다.
Records 는 주로 데이터를 저장하거나 어떤 동작을 정의하지 않는 상황에서 선택하는것이 좋다.
왜 Records 가 데이터를 저장하기에 좋은가?
- Records 를 사용하면 클래스의 각 필드에 대한 생성자 및 getter/setter 메소드를 정의하는 대신에 한 줄의 코드로 데이터 필드를 정의할 수 있다.
- 값을 기반으로 한 equals() 및 hashCode() 를 제공하여, 두 Records 인스턴스간의 비교를 쉽게 할 수 있다.
Data Transfer Objects (DTOs)
Records 는 어플리케이션의 데이터 전송을 하는데 사용되는 DTO 에 적합하다. Records 를 사용하면 몇 줄의 코드로 DTO 를 정의할 수 있어, 작성해야 하는 보일러플레이트 코드의 양을 줄일 수 있다.
public record PersonDTO(String firstName, String lastName, int age) {}
불변 객체(Immutable objects)
Records 는 기본적으로 불변이라, 인스턴스화 이후에 수정되지 않아야 하는 클래스인 경우에 사용하면 좋다. Records 를 사용하면 클래스를 불변으로 만들기 위해 어떤 코드도 작성할 필요가 없다. - 이것은 자동으로 처리가 된다.
public record Temperature(double value, String unit) {}
Simple value types
Records 는 간단한 값을 표현하는 클래스에 적합하다. 예를 들어, 2차원 공간에서 좌표를 나타내기 위해 사용할 수 있다.
public record Point(int x, int y) {}
API 응답
Records 는 API 에서 반환된 응답을 표현하는데 좋다. 레코드를 사용하면 필요한 필드만 가지고 있는 클래스를 정의할 수 있어 API 응답을 다루기가 더 쉬워진다.
public record ErrorResponse(int code, String message, String additionalInfo) {}
Configuration 설정
Records 는 configuration 설정을 나타내는데 적합하다. 레코드를 사용하면 필요한 필드만 가지고 있는 클래스를 정의하여 어플리케이션의 구성 설정을 관리하기가 쉬워진다.
public record DbConfig(String databaseUrl, String username, String password) {}
정말로 Records 가 필요한가?
그렇다고 말할 수 있다. 하지만 더 나은 방법이 있다. 롬복을 사용하면 보일러플레이트 코드를 줄일 수 있다.
Person Record
public record Person(String name, int age) {}
Lombok Annotated Person class
import lombok.AllArgsConstructor;
import lombok.Data;
@Data
@AllArgsConstructor
public class Person {
private String name;
private int age;
}
//@Data Annotation Generates getters for all fields, a useful toString method, and hashCode and equals implementations that check all non-transient fields. Will also generate setters for all non-final fields, as well as a constructor.
// Equivalent to @Getter @Setter @RequiredArgsConstructor @ToString @EqualsAndHashCod
하지만, 위에서 언급한 시나리오를 고려해보면, Records 를 사용할 몇 가지 이유가 존재한다.
- 간결함 -> 레코드는 속성과 생성자를 한줄의 코드에 정의할 수 있다. 롬복의 경우 동일한 기능을 정의하기 위하여 여러개의 어노테이션(@Data, @AllArgsConstructor)을 사용해야 하면, 이는 더 많은 코드를 작성하고 가독성이 떨어질 수 있다.
- 불변성 -> 레코드는 기본적으로 불변이며, 속성이 정의되면 변경할 수 없을을 의미한다. 이는 버그를 방지하고 코드 신뢰성을 향상시키는데 도움이 될 수 있다.
레코드와 롬복 어노테이션된 클래스 중 어떤 것을 선택할지는 요구사항과 개인 선호에 따라 달라질 수 있다. 간결성과 불변성을 중요시 하는 경우, 레코드가 더 나은 선택일 수 있다. 편의성과 코드 생성을 중요시하는 경우, 롬복 어노테이션된 클래스가 더 나은 선택일 수 있다.
레코드는 자바에서 최신 및 뛰어난 기능으로, 코드를 간결하게 만들고 가독성을 높이며 유지보수를 쉽게 할 수 있다. 간단한 데이터 구조든 복잡한 데이터 구조든, 레코드는 좋은 선택이 될 수 있다. 레코드를 롬복과 비교함으로써, 자바 프로그램에서 레코드를 사용하는 이점을 보여드렸습니다.
'Medium' 카테고리의 다른 글
| Spring Boot3 with QueryDSL - Part1 (0) | 2023.11.03 |
|---|---|
| Retry 와 Fallback 메카니즘을 활용한 스프링 마이크로서비스 회복탄력성 (0) | 2023.10.26 |
| 소프트웨어 엔지니어가 알아야 할 12가지 소프트웨어 아키텍처 스타일 (0) | 2023.10.23 |
| 스프링 마이크로서비스와 사이드카 패턴 (0) | 2023.10.19 |
| Spring Boot3 마이그레이션 (0) | 2023.10.17 |