혹시 @AllArgsConstructor 를 지양하시는 이유가 빌더 패턴을 사용하기 위함인가요?

안녕하세요, 최종민 님!

아뇨, 빌더 패턴과는 무관합니다.
빌더 패턴은 빌더 패턴의 장점이 별도로 있기 때문에 사용하는 것이고, @AllArgsConstructor 를 사용하지 않는 이유는 별개의 이유입니다.

@AllArgsConstructor는 편리하게 모든 필드를 가진 생성자를 만들어 주지만, 필드의 순서가 변경되는 경우 치명적일 수 있습니다.
예를 들어 어떤 객체가 2개의 String 타입을 필드로 가지고 있고, 이에 대한 생성자를 외부에서 사용하고 있다고 가정해 봅시다.
해당 객체의 필드 순서가 실수로 변경되어도 컴파일 에러가 발생하지 않고, 추후 인지하지 못한 치명적인 버그가 발생할 수 있는 여지가 됩니다.

그럼 @RequiredArgsConstructor를 사용해도 final 키워드만 붙었지 마찬가지 아닌가, 싶으실텐데요. 맞습니다. AllArgs~와 동일한 문제를 안고 있지만, 저는 그래도 편의성을 위해 @RequiredArgsConstructor정도는 인지하고 사용하자는 편입니다.
이유는 다음과 같은데요.

• 사용자가 final 키워드를 붙이면서 필수 파라미터에 대한 인지를 하고 필드를 선언한다는 점

• 스프링에서는 객체의 생성자만 만들어두면 스프링에서 알맞은 타입과 이름의 빈을 찾아서 주입해주기 때문에, 필드 순서가 바뀌거나 해도 타입+이름 기반으로 동작하니 @RequiredArgsConstructor 를 사용해도 큰 무리가 없음

  • 다만 스프링의 Bean이 아닌 사용자가 직접 만들고 사용하는 일반 객체라면, 위 문제를 방지하기 위해 @RequiredArgsConstructor 대신 그냥 생성자를 사용해보는 것을 고려해볼 수 있습니다.

도움이 되셨기를 바랍니다.
감사합니다~! 🙂

안녕하세요, 인프런 AI 인턴입니다.

최종민님, @AllArgsConstructor를 지양하는 이유는 여러 가지가 있을 수 있습니다만, 말씀하신 것처럼 빌더 패턴을 사용하기 위한 목적일 수도 있습니다. 빌더 패턴은 객체 생성 시 명확한 이름을 가진 메소드를 통해 가독성을 높이고, 필요한 속성만으로 객체를 생성할 수 있는 유연함을 제공합니다. 또한, 객체의 불변성을 유지하기 쉬우며, 매개변수가 많을 때 사용성이 좋기 때문에 @Builder 어노테이션을 통해 빌더 패턴을 사용하기도 합니다.

그러나 이것이 반드시 모든 상황에서 빌더 패턴이 좋다는 것은 아닙니다. 맥락과 요구사항에 따라 @AllArgsConstructor, @RequiredArgsConstructor, 빌더 패턴 등 다양한 생성 방식 중 하나를 선택할 수 있을 것입니다.