[Item04] 인스턴스화 방지, setter 막아두기 과연 옳은가

프로젝트를 진행하다 보면 문자열, 숫자 상수만을 담은 Constant 클래스를 작성할 때가 종종 있다

다양한 클래스에서 사용할 수 있는 Utility 클래스도 마찬가지다

두 클래스의 목적은 특정 클래스에 속하지 않으면서 프로젝트 전체에서 유용하게 사용할 수 있는 코드를 일반화하는 것이다

 

상수 클래스의 경우 public static final로 한 번만 초기화된 상태로 변경할 수 없도록 해두고

유틸리티 클래스의 경우 public static 으로 접근을 허용하며 메서드를 가진 클래스의 인스턴스화 없이도 사용하게 한다

따라서 두 클래스 모두 인스턴스화될 필요가 없으니 생성자를 private으로 두어 상속 / 인스턴스화를 할 수 없게 해야 한다

 

사실 상수, 유틸리티 클래스는 인스턴스화 될 필요가 없고 되면 낭비일 뿐이니 private으로 막아두는 게 당연하다

이번 장의 주제와는 다르지만 결이 비슷한 내용으로 생각해봤는데 제약을 두어 안전한 방식으로 만드는데 의문이 든다

대표적으로 Entity에서 setter를 막아두는 관례가 그러하다

 

Entity - DTO 매핑에서 아주 유용한 MapStruct는 매핑을 위해 setter가 필수적이다

정확히는 단순 매핑에는 생성자나 빌더 패턴을 이용해 매핑할 수 있어 필수는 아니지만

입력받은 값으로 생성된 Request DTO에서 Entity를 바로 업데이트칠 때 필요하다

물론 이 방법도 우회하는 방법이 존재하는데 MapStruct 기본 설정에서는 setter를 기준으로 필드를 바꾸는데

필드 접근 메서드의 이름을 설정하여 changeXXX, editXXX과 같이 바꿔주면 되긴 한다

다만 이 방식은 이름만 바꾼 setter일 뿐이다

 

그렇다면 MapStruct의 힘을 빌리지 않고 DTO에서 값을 꺼내

Entity에서 만들어둔 변경 메서드를 사용하면 되지 않을까 하는 의문을 가질 수 있지만

그런 방식으로 문제를 풀려고 한다면 매핑 라이브러리도 사용할 필요가 없다

지루한 Entity - DTO 매핑을 해결하기 위해 나온 라이브러리를 온전히 이용하지 않는 것이다

 

또한 Entity에서 만들어두는 변경 메서드 또한 직접 필드 접근이나 setter를 이용한 우회 접근으로 필드를 변경한다

프록시를 사용할 때 안전하게 사용하려면 직접 필드 접근 대신 getter, setter를 사용해 우회 접근해야 한다

어찌 됐든 변경 메서드 자체도 의미 있는 이름을 가진 setter 메서드일 뿐이다

setter 남발이나 changeXX 등의 변경 메서드 남발이나 똑같다

도메인계층에서 수행되는 setter는 나쁘다고 할 수 없는데 컨트롤러, 뷰 계층에서의 setter는 지양해야 한다

중요한 것은 어디서 변경이 이루어지고 어디서 변경이 되면 안 되는지 구분하는 것이다

 

결론은 변경 범위가 넓어진다고 하여 setter를 막아두는 것이 과연 합리적인가 하는 생각이다

MapStruct 사용할 때 setter를 막아두는 관례와 충돌하기 때문에 불편해서가 가장 큰 이유이긴 한데

안전한 개발을 위해 손발을 다 잘라버리고 특정 방식으로 메서드를 만들도록 강제하는 게 옳은 것인가?

물론 setter 남발은 변경 추적이 어려워지는데 이 정도는 팀의 합의로 풀어나갈 수 있지 않을까 싶다

팀 컨벤션으로 IDE의 indent를 몇이나 줄 것이고 줄 바꿈은 어떻게 할 것인지도 정하는데

도메인 / Entity 매핑 시에만 setter 사용하고 나머지에서는 사용하지 말라고 강제하는 것이 어려울 것도 아니다

개인 프로젝트에서는 Entity와 MapStruct만 setter를 사용할 수 있도록 하고

서비스 & 컨트롤러 계층에서 사용하지 않게 컨벤션을 유지해 아주 유용했는데 실무에서는 쓰지 못할 것 같아 아쉽다