왜 엔티티에 Setter를 사용하면 안 될까?

강의를 참고하여 비밀번호 수정 기능을 구현하던 중, 왜 단순히 Setter를 사용하지 않고 updatePassword() 메서드를 따로 만들어야 하는지 의문이 들었다.

public void updatePassword(String password) {
    this.password = password;
}

 

Member 엔티티에서 아래와 같이 @Setter를 password 필드 위에 추가하면 안되는 것일까?

@Setter
@Column(nullable = false)
private String password;

 

찾아보니 Setter의 사용을 지양하는 이유는 여러가지가 있었다.

 

1️⃣ Setter를 사용하면 객체의 일관성을 유지하기 어렵다.

• 어디서든 값이 변경될 수 있어 데이터 무결성이 깨질 위험이 있다.

2️⃣ Setter를 사용하면 변경의 의도가 불분명하다.

• setPassword()만 보면 이 메서드가 비밀번호 변경을 위한 것인지, 처음 설정하는 것인지 알기 어렵다.

3️⃣ 비즈니스 로직을 명확하게 분리할 수 없다.

• 비밀번호 변경 시 기존 비밀번호 검증 같은 추가 로직이 필요할 수도 있다.

4️⃣ 결과적으로 유지보수가 어렵다.

• 여러 곳에서 Setter를 호출해버리면, 이후 로직 변경이 필요할 때 모든 코드에서 변경해야 한다.

결국, Setter를 사용하면 데이터의 무결성이 깨질 가능성이 높고, 유지보수도 어려워진다.

따라서, 비밀번호 변경 로직을 updatePassword() 같은 명확한 메서드로 분리하는 것이 바람직하다.

이렇게 하면 객체의 일관성을 유지하면서, 비즈니스 로직을 더욱 명확하게 관리할 수 있다.