2024. 6. 17. 11:49ㆍJPA
우연히 setter와 getter의 무분별한 사용을 지양하라는 말을 듣게 됐다.
클래스를 만들 때 정말 당연하단 듯이 @Setter @Getter를 이용했는데...?
객체 지향의 원칙 중 하나는 정보 은닉이다. 필드는 private이지만 setter와 getter가 public인 이상 private으로 지정한 필드는 public과 다를 게 없다고 한다.
타 개발자들의 글을 읽어 보면 여러가지 예를 보여주면서 setter와 getter를 지양해야 하는 이유와 setter와 getter의 직접적인 사용을 대신할 수 있는 다른 방법을 설명해준다.
이러한 설명은 모두 끝내 한 지점으로 연결된다. 무분별한 getter와 setter의 사용은 객체 지향의 핵심인 정보 은닉을 해치게 된다는 것. 외부에서 객체의 상태를 알고, 수정할 수 있으면 안된다는 것. 객체의 상태가 변경됐을 때 의도하지 않은 동작의 수행 역시 문제가 된다고 한다.
외부 결제 API를 연동해서 Payment 객체를 이용할 때, Payment 객체 안에 setter가 없다는 걸 처음으로 알게 됐다. 값을 받아오는 getter만 존재했다. 만약 setter가 존재했다고 가정해보자.
객체에 접근해 여러 중요한 정보(결제에 있어 상품에 대한 고유값), 심지어 가격까지 수정할 수 있는 문제가 발생한다. 특히나 외부와의 연동에 있어, 값의 불일치가 발생할 경우 예상치 못한 에러가 연쇄적으로 일어날 가능성도 있다.
public class MyPayment {
private String imp_uid;
private String merchant_uid;
private String status;
public String getimp_uid() {
return imp_uid;
}
public void setimp_uid(String imp_uid) {
this.imp_uid = imp_uid;
}
public String getmerchant_uid() {
return merchant_uid;
}
public void setmerchant_uid(String merchant_uid) {
this.merchant_uid = merchant_uid;
}
public String getStatus() {
return status;
}
public void setStatus(String status) {
this.status = status;
}
}
json 관련 문제로 내가 아무렇지 않게 만들었던 클래스다. 이렇게 되면 우려한 문제가 실제로 일어나게 된다. 상품에 대해 결제 완료, 환불, 취소만 가능하게 하면 될 뿐이지 imp_uid, merchant_uid를 수정해야 할 일이 있을까? 정보 은닉을 위해 setter와 getter의 생성 여부를 판단해야 할 것이다.
아직 무분별한 setter와 getter의 생성으로 에러를 마주한 적이 없다. 나 같이 단순한 프로젝트를 진행한다면 에러를 마주하지 않을 확률이 높을 것이다. 조금 더 객체 지향적인 프로그래밍에 대해 공부해야 할 거 같다. 타 블로그에 나온 것처럼 객체에 대한 정보를 수정했을 때, 무분별한 getter의 생성이 어떻게 프로그램에 에러를 일으키는지. setter의 생성이 어떤 방식으로 정보 은닉이라는 원칙을 파괴시킬 수 있는지 말이다. 아마 지금 쓴 글은 추후에 또 하나의 사례를 들고 이야기해야 할 것이다.
'JPA' 카테고리의 다른 글
[JPA] N+1 문제? 이렇게 많은 쿼리문이 수행될 줄 몰랐지 (0) | 2024.06.21 |
---|---|
[JPA] FetchType.EAGER의 남용과 순환 참조 그리고 N+1 (0) | 2024.06.20 |
[JPA] ddl-auto=create 테이블 drop 에러가 난다면 (0) | 2024.06.19 |