💡 한줄요약
정확히는 객체 수정 메소드를 구현하지 말라는 뜻이 아니라,
setXYZ()라는
1) 무책임한 메소드명
2) 데이터를 변경하는 기능만 보유(변경 가능 여부 검사)
3) public이란 오픈된 접근 제어
메소드를 모든 필드에 대해 구현하는 것이 위험하단 의미이다!
흔히 엔티티(도메인)을 정의한 클래스에서 @Setter 를 구현하지 말아야 하는 이유로 “누구나 변경 가능하기 때문”이란 근거를 든다.
내 의문은, ‘도메인에서 수정 메소드를 정의하려면 피치 못하게 public이어야 하고, 그럼 어떻게 정의하든 결국 누구나 변경 가능한 것 아닌가?’ 하는 딜레마였다.
이는 객체지향 설계 원칙을 제대로 이해하지 못해 든 의문이었다.
한줄요약에서 설명한 ‘위험한 이유 3가지’를 하나하나 분석해보자.
1. 무책임한 메소드명
⇒ 값을 변경하려는 목적을 분명히 담은 메소드명을 부여하자
2. 무지성 데이터 변경으로 도메인 로직 분산
‘속성을 변경할 수 있는 조건’ 이란 건 도메인의 핵심 규칙들 중 하나이다.
@Setter 를 통해 자동으로 만들어지는 setXYZ() 함수의 내부엔 당연하게도 XYZ란 필드에 할당된 값을 변경하는 문장 밖에 없다.
따라서 set메소드를 사용하면서도 조건을 검사해 값을 변경하고 싶다면 service 단에서 조건 검사를 수행해야 하는데,
이는 명백한 SRP 위반이다!
⇒ 필드 변경을 위한 모든 로직은 도메인 내부에 구현하되, 규칙마다 변경 메소드를 분리해서 구현하자[SRP]
public 이란 오픈된 접근 제어
⇒ (권장) <조건 검사 + 실제 필드 변경()>인, 비즈니스 로직에서 사용할 변경 메소드는 public으로 / 변경 메소드 로직에 포함된 실제 필드 변경 메소드는 private으로 구현하자
이 솔루션은, 실제 필드 변경 메소드가 ‘공통 조건 검사 로직’을 포함할 때 가장 효율적이다!
그럼 setXYZ()는 볼드모트인가?
아니다!
분명한 목적을 가지고, 엄격한 규칙(변경 조건 검사) 하에, 허용된 범위 하에서만 사용하도록 허용한다면 분명히 유의미한 메소드가 될 수 있다.
위에서 말한 ‘실제 필드 변경 메소드’는 공통으로 적용되는 규칙 하에, private에서 사용되므로 올바른 설계에 해당한다.
