공부한 이유
평소 개발을 하다가 무분별하게 @Data 어노테이션을 사용해서 @getter와 @setter 의 사용을 남발하곤 했다. 이전에 코드리뷰를 받았던 내용 중에 getter와 setter 사용을 최대한 지양하라는 말을 들었고, 공부하면서 많이 들은 말이지만 정작 왜 쓰면 안 되는가? 에 대해 답을 할 수 없었다. 또 기존 프로젝트에서 update로직을 구현할 때 setter를 사용했기에, 이를 변경해보고자 왜 쓰면 안 되는지, 안 쓴다면 어떻게 해야 하는지를 파헤쳐 보기로 했다.
setter를 쓰면 왜 안 되는가?
- 다른 사람이 코드를 보거나, 나중에 본인이 짠 코드를 봤을 때, 값을 변경한 의도를 파악하기 어렵다. 즉 코드를 역추적해봐야 한다. 값을 넣어야할 필드가 많아지면 무분별하게 setter가 나열된다. setter를 나열하기만 하면 어떤 의도로 데이터를 변경한 것인지 명확하지 않다.
- 객체의 일관성이 떨어진다. setter로 값을 변경할 수 있다면 모든 곳에서 객체 값의 변경이 가능한데, 객체의 값을 변경하는 메소드가 의미가 왜 필요하겠는가. 또 setter 때문에 의도치 않게 값이 변경될 수 없는 위험이 존재하므로 사전 차단해야 한다.
Getter 를 쓰면 왜 안 되는가?
캡슐화의 의미가 없어진다. private으로 필드를 선언해놓고 getter로 아무 곳에서나 값을 꺼내올 수 있다면 상태 정보가 그대로 노출되는데 private을 굳이 선언한 의미가 없어진다.
setter를 안 쓰고 어떻게 할 수 있는가?
- 첫 번째 방식은 엔티티의 생성자를 사용하여 값을 변경하는 것이 아닌, 완전히 초기화하는 방식을 택한다. 그런데 이 방법은 생성자를 쓸 때 각각의 매개변수의 의미를 파악하기 어렵고, 상황에 따라 특정 매개변수만 초기화하는 경우도 있는데 이 경우 일일이 생성자를 써야 하므로 코드가 혼잡해진다
- 빌더 패턴을 활용해서 매개변수의 의미를 파악하기 쉽게 하고, 선택적으로 필요한 변수는 값을 초기화해주어 매개변수 대응을 해결한다.
getter를 안 쓰고 어떻게 할 수 있는가?
로직을 객체에 존재하게 하여, 메소드가 상태값을 모른 채로 객체에게 질문을 하도록 해야 한다. 예를 들어 어떤 값이 객체의 상태값과 같은 지 확인을 하려면, 특정 값을 객체에게 넘겨주고 이 값이 같은지 안 같은지 여부만을 응답받는 식으로 설계한다!
Getter를 써도 되는 경우는 어떤 것인가?
값을 출력하기만 할 때나, responseDTO 처럼 멤버변수 값의 전달을 위해 필요한 경우 Getter를 사용할 수 있다.
하마드