Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
Tags
- join
- MySQL
- 안드로이드
- 코테
- 스터디
- 자료구조
- 정처기
- select
- 기술면접
- 혼공파
- 자바
- 카카오코테
- Til
- CS
- Android
- doitandroid
- SQL
- groupby
- 인프런
- 정보처리기사
- 코틀린
- 안드로이드스튜디오
- 혼공단
- 혼공챌린지
- 오블완
- 알고리즘
- Kotlin
- java
- 프로그래머스
- 티스토리챌린지
Archives
- Today
- Total
Welcome! Everything is fine.
[Spring] 왜 엔티티에 Setter를 사용하면 안 될까? 본문
728x90
강의를 참고하여 비밀번호 수정 기능을 구현하던 중, 왜 단순히 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() 같은 명확한 메서드로 분리하는 것이 바람직하다.
이렇게 하면 객체의 일관성을 유지하면서, 비즈니스 로직을 더욱 명확하게 관리할 수 있다.
'TIL' 카테고리의 다른 글
[Spring] Converter와 Fomatter 사용하기 (0) | 2025.02.21 |
---|---|
[Git] 로컬 브랜치에서 pull 할 때 에러 발생 - stash로 임시 커밋하기 (0) | 2025.02.18 |
[Spring] INSERT 됐지만 테이블이 안 보이는 문제 - @Transactional (0) | 2025.02.12 |
[Spring] Spring에서 @RequestBody를 사용할 때 주의해야 할 점 (0) | 2025.02.04 |
[Spring] queryForObject() vs query() (0) | 2025.02.03 |