@EqualsAndHashCode

Q. 프로젝트에서 Request Dto에 다 @EqualsAndHashCode를 추가하셨는데, 왜 추가하셨고 추가 안했을때는 어떠한 문제가 있나요?

@EqualsAndHashCode는 Lombok에서 제공하는 애노테이션으로, equals()와 hashCode() 메서드를 자동 생성합니다. callSuper 옵션을 사용하면 부모 클래스의 필드까지 포함할지 결정할 수 있습니다.

제가 작업한 '로아투두' 프로젝트에서는 대부분의 Request DTO에 characterId가 공통적으로 필요해서, 이를 부모 클래스에 정의하고 다른 Request DTO들이 부모 클래스를 상속받도록 설계했습니다. Request 객체 간 비교가 필요할 때, 부모 클래스의 characterId까지 고려해야 하므로 @EqualsAndHashCode(callSuper = true)를 적용했습니다.

물론 비교 로직이 필요 없는 DTO라면 이 애노테이션을 제거하는 게 맞지만, 프로젝트 전체의 일관성을 유지하기 위해 모든 Request DTO에 통일해서 적용했습니다.

Q. characterId를 부모 클래스에 넣고 상속받는 구조를 선택했는데, 상속 대신 컴포지션(composition)을 사용하면 안 됐을까요? 상속의 단점은 고려했나요?

컴포지션도 좋은 대안이 될 수 있습니다. 상속은 부모와 자식 간 강한 결합도를 만들 수 있어, 부모 클래스가 변경되면 모든 자식 DTO에 영향을 줄 수 있다는 단점이 있습니다. 하지만 이 프로젝트에서는 characterId가 모든 Request에 필수적이고, 코드 중복을 줄이기 위해 상속을 선택했습니다. 컴포지션은 더 유연하지만, DTO처럼 단순한 데이터 구조에서는 상속으로도 충분하다고 판단했습니다.

• 상속(Inheritance): 상속은 'is-a' 관계를 나타내며, 자식 클래스가 부모 클래스의 속성과 동작을 물려받아 재사용합니다. 이 경우, 부모 클래스에 characterId를 정의하면 모든 자식 DTO가 이를 자동으로 갖게 됩니다. 장점은 코드 중복을 줄이고 구현이 간단하다는 점입니다. 하지만 부모 클래스의 내부 변경(예: 필드 추가/삭제)이 자식 클래스에 직접 영향을 주며, 결합도가 높아져 유연성이 떨어질 수 있습니다.

• 컴포지션(Composition): 컴포지션은 'has-a' 관계를 나타내며, 객체가 다른 객체를 포함하는 방식으로 구성됩니다. 예를 들어, characterId를 별도의 클래스나 객체로 정의하고, 각 DTO가 이를 필드로 가지게 할 수 있습니다. 이는 부모-자식 관계 대신 독립적인 객체를 조합하므로 결합도가 낮고, 특정 DTO에서 characterId의 동작을 변경하거나 생략하기 쉬워 유연성이 높습니다. 단점은 약간의 코드가 늘어나고 설계가 복잡해질 수 있다는 점입니다. 이 프로젝트에서는 DTO의 역할이 단순히 데이터를 전달하는 데 초점이 맞춰져 있고, characterId가 모든 Request에서 공통적으로 필요하다는 점에서 상속의 간결함이 더 적합하다고 봤습니다. 하지만 요구사항이 복잡해지거나 DTO 간 독립성이 중요해진다면 컴포지션으로 전환하는 것도 고려할 수 있습니다.