JPA setter 사용

Question

JPA를 공부하고 있습니다.영속 상태에서 값 변경과 관련해 질문이 있습니다.Member member = new Member(); member.setId(1L); member.setName("abc"); em.persist(member);위와 같이 엔티티를 영속화해서 사용할 때, 보통은 빌더 패턴이나 생성자를 통해 값을 세팅한 뒤 영속성 컨텍스트에 올리라고 합니다.DTO는 보통 setter/getter를 만들어 값을 변경하며 사용하지만, 엔티티에서는 setter 사용을 지양하라고 합니다.그렇다면 값을 어떻게 변경해야 할까요? 다음과 같이 메서드를 만들라고 합니다.void changeName(String name) { this.name = name; }그런데 이것이 결국 setter를 구현한 것과 어떤 차이가 있는지 잘 모르겠습니다.또한 엔티티 필드가 많고 모든 값이 변경 가능하다는 전제라면, 모든 필드에 대해 이런 메서드를 전부 만들어야 하는지도 궁금합니다.

chytonpide · Accepted Answer

Entity 를 데이터로 보지않고 오브젝트 로 보면, setter 는 어색해지고 operation(객체에게 보내는 메세지)이 자연스러워 집니다.오퍼레이션을 사용해서 오브젝트의 불변식을 지킬 수 있습니다.예를들어서 아래와 같이 오퍼레이션을 정의하면 passwordEncryptionService 를 통해서만 패스워드를 변경할 수 있겠지요.changePassword(String newPassword, PasswordEncryptionService passwordEncryptionService)꼭 불변식때문이 아니여도 문제영역에서 사용되는 용어가 그대로 오퍼레이션이 되기도 합니다.유저식별하기라는 문제영역에서 사람들이 "프로필 변경"이라는 용어를 사용하고 있고, 이게 이름과 닉네임을 변경하는것 이라면,코드상에 다음처럼 오퍼레이션이 정의되는게 여러모로 의사소통을 하기 편하고, 명확해 집니다.changeProfile(Name name, String nickname)또 이렇게 정의된 오퍼레이션은 시스템 전체에서 하나의 논리적인 단위로 사용될 수도 있습니다.예를들면, changeProfile 내에서 다음과 같이 이벤트를 발행할 수 있습니다.DomainEventPublisher.instance().publish(new MemberProfileChanged(this.name, this.nickname));이런 표현은 setter로는 하기가 힘들지요.change 만 가지고 예를 들었는데 자신의 상태를 관리하는 오브젝트 는 자연스럽게 오퍼레이션을 가지게 됩니다.예를 들어서 구독 문제영역에서 "구독을 만료시킨다" 라는걸 시스템에서 표현하려고 할때,Subscription 을 데이터 모델로 보면 아래처럼 클라이언트에 책임을 두고 setter 를 사용해서 프러퍼티를 변경할 수 있습니다.LocalDate endDate = subscription.getEndDate(); List<SubscriptionItem> subscriptionItems.getSubscriptionItems(); ... 구독과 관련된 조건에 따른 다른 상태 변경... if(endDate < baseDate) { ... subscription.setItems(newSubscriptionItems); ... } else { ... } // 최종적으로 조건을 충족한다면 상태를 변경 subscription.setExpired(true);만약 Subscription 을 오브젝트로 보면 다음과 같이 오퍼레이션을 실행할 수 있습니다.subscription.expire(baseDate);이렇게 하면 모든 상태변경 로직은 subscription 안에 갇혀있게 되고 클라이언트는 expire 만 호출하면 됩니다.구독 만료에 대한 지식을 expire 오퍼레이션안에 가두는걸로 응집도를 놉히면, 생각하기 쉽고(의도를 파악하기 쉽고), 의사소통하기 쉽고, 심지어 테스트하기도 쉬워집니다.이 오퍼레이션이 이벤트를 발행한다면 시스템내에 SubscriptionExpired 표현이 생기고 이걸 활용할수 있게 되기도 하구요.

캐티 · Answer

공용으로 지정한 프로퍼티를 변경하는 거는 안하나요. 전통적인 프로그래밍은 본래 이렇게 하는 거였어요. 특별한 이유가 있었다 이럼 보호를 걸어서 프로그래머가 임의로 사용하지 못하게 하여쩌.

고등어통조림 · Answer

의식을 안 하고 있다가 질문내용을 보다보니 궁금해서 ai 한테 물어봤습니다.—-————————-changeName()과 setter의 차이말씀하신 것처럼 changeName(String name)은 결국 this.name = name;을 하는 건데,핵심은 “의도와 의미를 드러내는 이름”을 가질 수 있다는 점입니다.// 단순 setterpublic void setName(String name) { this.name = name;}// 도메인 메서드public void changeName(String name) { this.name = name;}두 코드가 하는 일은 같지만, 차이는 도메인 용어로 의도를 표현하느냐입니다.실제 비즈니스 로직에서는 이렇게 발전할 수 있어요:public void changeName(String name) { if (name == null || name.isBlank()) { throw new IllegalArgumentException("회원 이름은 필수입니다."); } this.name = name;}→ 단순 setter였다면 null이나 빈 문자열도 그냥 들어가 버렸을 거예요.즉, 도메인 규칙을 강제하는 통로로서 의미가 있습니다.

고등어통조림 · Answer

필드가 많으면 모든 changeXXX()를 만들어야 할까?무조건은 아닙니다. 원칙적으로는 *“실제로 변경이 필요한 속성”*에만 도메인 메서드를 정의하면 됩니다.항상 바뀌는 값 (예: 배송 상태, 주문 상태, 회원 등급)→ changeStatus(), upgradeGrade() 같이 의미 있는 메서드로 제공거의 바뀌지 않는 값 (예: 회원 가입일, PK, 생성자에서만 넣는 값)→ 아예 변경 메서드 제공하지 않음 (불변으로 유지)즉, 필드 개수 = 변경 메서드 개수 가 아닙니다.“업데이트가 필요 없는 필드”에는 아예 세터/체인지 메서드를 두지 않는 게 좋아요.4. 정리엔티티에서 setter를 막는 이유: 객체 무결성과 의도 없는 값 변경 방지changeName() 같은 도메인 메서드는 단순 대입이 아니라 의미/검증/비즈니스 규칙을 표현하는 수단모든 필드에 만들 필요 없음 → 실제 도메인 로직에서 “의미 있는 변경”이 필요한 필드에만 만들기

고등어통조림 · Answer

실제 서비스에서는 어떤 값들이 언제, 왜 변경되는지 명확히 하기 위해 변경 포인트마다 의미 있는 이름의 메서드를 적절히 추가하는 것이 ‘관례적’입니다

뭐라이름을지을지모르겠어Yo · Answer

저도 이런부분으로 많은 고민을 했었어요.많은 분들이 답변을 해주셨지만 한마디 보태자면 유지보수성에 대한 이유도 있는 것 같습니다.setAlt(); setLat(); setLon();이렇게 써져있다면 위도,경도,고도에 대한 어떠한 비즈니스 로직이라는 것은 알 수 있습니다.그리고 메소드명과 주석을 통해 어떠한 비즈니스 로직인지 파악을 할 것입니다.허나 메소드명과 주석이 제대로 되어있지 않다면,값들이 많아질수록 파악이 어려워지는 문제가 발생한다고 생각합니다.이러한 문제로 setter를 지양하는 이유도 있다고 생각합니다.그리고 캡슐화의 원칙이 위반되는 사유도 존재합니다.무분별한 객체 생성을 막고자 이러한 기능을 많이 씁니다.access = AccessLevel.PROTECTED객체 내부를 직접 변경하게 됨으로 예기치 못한 동작을 만들 수 있기때문입니다.그리고 이에 따른 정보은닉도 위반된다고 생각합니다.저희는 개발할때 모든 필드를private 로 하시고 있을 겁니다.이러한 것을 쓰는 이유는 객체의 정보를 외부에 알리지 않기 위함이기도 하다고 생각합니다.그 이외 다른 분들도 설명을 잘 해주신것같습니다.그러면 setter를 쓰면 안되냐고 묻는다면 전 최대한 지향하라는 말을 할 것 같습니다.이미 많은 로직에 setter를 적었다면 지금부터라도 최대한 지양하는 방향으로 가시면 될 듯합니다.그리고 DTO에서도 setter를 잘 쓰지는 않는것같습니다.DTO에서도 객체의 불변성을 유지하는것이 좋기에 안쓰는게 좋다고 생각됩니다.

kmksk · Answer

getter/setter는 OOP에서 흔히 쓰이지만, 무분별하게 사용하면 캡슐화와 추상화를 해친다.캡슐화 위반: private 필드라도 getter/setter를 열어두면 사실상 외부에 그대로 노출된다.높은 결합도: 내부 구조가 외부 로직에 직접 연결되므로 리팩토링 시 수정 범위가 커진다.불필요한 코드: 관행적으로 추가되는 getter/setter는 실질적인 가치를 주지 않고 코드만 복잡하게 만든다.더 나은 접근은 데이터를 직접 노출하지 않고, 의미 있는 동작을 메서드로 제공하는 것이다. 예를 들어 age를 외부에 공개하기보다 isAdult() 같은 기능을 제공하면 추상화 수준을 높이고 변경에 유연해진다.결론: getter/setter 자체가 나쁘다기보다, 필요 없는 getter/setter 남용이 문제다. OOP의 핵심은 데이터를 숨기고 의미 있는 행동으로 드러내는 데 있다.

JPA setter 사용

7개의 답변

#setter 목록