[TIL]20240713 Entity에 @Setter어노테이션을 사용하지 않는 이유?

기술매니저님의 코드리뷰를 들으면 엔티티에 @Setter어노테이션을 쓰지말라고 하시고선 이유는 절!대! 안알려주신다. 직접 알아보라고 하시지... 진짜 명확한 이유를 듣고싶은데, 그래도 이런거 찾아보는게 공부니까.. 근데 매니저님.. 진짜 왜 안 알려주시는거에요....? 

엔티티 클래스는 데이터베이스와의 매핑을 통해 데이터를 영구적으로 저장하고 관리하는 중요한 역할을 하기때문에 설계 시 주의할 점이 많다. 왜 @Setter 어노테이션을 사용하는 것이 좋지않은 이유는 뭘까? 

 

▶ @Setter 어노테이션이란?

@Setter 어노테이션은 Lombok 라이브러리가 제공하는 기능 중 하나로, 클래스의 필드에 대한 setter 메서드를 자동으로 생성해준다. 이 어노테이션을 사용하면 코드가 간결해지고, 수동으로 메서드를 작성하는 번거로움을 줄일 수 있다. 하지만 엔티티 클래스에 @Setter를 남용하면 여러 문제가 발생할 수 있다. ← 어노테이션 하나가 남용이야...? 

 

▶ 엔티티에서 @Setter를 지양해야하는 이유

1. 엔티티의 무분별한 변경 가능성 :

엔티티 클래스에 @Setter를 사용하면 모든 필드에 대한 setter 메서드가 자동으로 생성되기 때문에, 어디서든 엔티티의 상태를 변경할 수 있게 된다. 이런 방법은 객체의 무결성을 해치고, 의도치 않은 상태 변화로 이어질 수 있기때문에 유지보수성과 안정성을 떨어뜨린다.

2. 엔티티의 불변성(Immutability) 유지 :

엔티티는 데이터베이스의 상태를 반영하는 중요한 객체이기 때문에, 가능한 불변(immutable)하게 유지하는 것이 좋다. 불변성은 객체가 생성된 이후 내부 상태가 변하지 않음을 보장하면서, 버그를 줄이고 예측 가능한 코드를 작성하는 데 도움을 준다. @Setter를 사용하면 불변성을 유지할 수 없게 된다.

3. 명확한 의도를 가진 메서드 설계 필요성 :

엔티티의 상태 변경은 비즈니스 로직에 따라 신중하게 이루어져야 한다. 예를 들어, 메모 애플리케이션에서 메모의 내용을 수정할 때는 updateContents()와 같은 명확한 의도를 가진 메서드를 통해 수정해야 한다. @Setter를 사용하면 명확성이 사라지고, 코드의 가독성도 떨어지게 된다.

4. 캡슐화 원칙 위반:

엔티티의 필드가 외부에서 무분별하게 수정될 수 있다는 것은 캡슐화(Encapsulation) 원칙을 위반하는 것이다. 캡슐화는 객체지향 설계에서 중요한 원칙으로, 객체의 내부 상태를 외부에서 직접 수정하지 못하도록 보호하는 것을 의미한다. @Setter는 이러한 원칙을 쉽게 깨뜨리게 된다.

5. 일관성 있는 비즈니스 로직 유지:

엔티티의 필드가 무분별하게 수정될 수 있으면, 일관된 비즈니스 로직을 유지하기 어려워진다. 이런 문제는데이터 불일치 문제를 일으킬 수 있고, 장기적으로 애플리케이션의 유지보수성을 크게 저하시킨다.

 

▶ 올바른 엔티티 설계 방법

엔티티는 다음과 같은 방법으로 설계하는 것이 좋다

→ 생성자 또는 정적 팩토리 메서드 사용:

객체 생성 시 필수 필드를 초기화헤서 불완전한 상태의 객체가 생성되지 않도록 한다.

→ 명확한 도메인 메서드 정의:

updateContents(), changePassword()와 같은 비즈니스 로직에 맞는 메서드를 정의해서 엔티티의 상태를 변경하도록 한다.

→ 필드의 불변성 유지:

되도록이면 엔티티의 필드를 final로 선언하고, 필요한 경우 값 변경 로직을 메서드로 캡슐화하여 불변성을 유지한다.

 

▶ 정리 

엔티티 클래스에 @Setter 어노테이션을 사용하지 않고, 명확한 비즈니스 로직에 따른 메서드를 설계해서 코드의 안전성과 유지보수성을 높이는 데 중점을 두는 것이 좋다. 엔티티는 애플리케이션의 핵심 데이터를 다루는 중요한 객체이기 때문에, 설계 시 신중함이 필요하다. 객체의 무결성을 유지하면서 일관된 비즈니스 로직을 구현하기 위해서는 엔티티 설계 원칙을 철저히 준수하는게 좋다!