Setter를 지양하자

Setter를 지양해야 하는 이유?

1. Setter를 사용할 경우에는 코드만 보았을때 한번에 뚜렷한 목표를 알기 어렵다.
2. 객체의 역할 분리로 VO/DTO 가 가져가야할 Validation 영역이 Service 레이어에 남는다.

예시를 들자면 다음의 시나리오에서

1. 유저의 활성화 상태를 변경한다
   • 이미 활성화 된 유저는 또 활성화할 수 없다.
   • 이미 비활성화 된 유저도 또 비활성화할 수 없다

// 이런 코드보다
public activateUser(){
  User user = userRepository.findById(1L);
  
  if(user.isActivate()) throw new IllegalArgumentException("이미 활성화 된 유저");
  
  user.setActivated(true);
  userRepository.save(user);
}

public deActivateUser(){
  User user = userRepository.findById(1L);

  if(!user.isActivate()) throw new IllegalArgumentException("이미 비활성화 된 유저");
  
  user.setActivated(false);
  userRepository.save(user);
}


//아래와 같은 코드가 역할 분리도 확실하고, 의도도 명확하다는 것이죠.
// 사람과 대화할 때에도 애매모호한 단어로 대화하는 것보다 A는 A B는 B 라고 대화 하는것이 의사소통이 더욱 잘되는 것과 같은 맥락입니다.

public activateUser(){
  User user = userRepository.findById(1L);

  user.activate();
  userRepository.save(user);
}

public deActivateUser(){
  User user = userRepository.findById(1L);

  user.deactivate();
  userRepository.save(user);
}


public class User{
....
  public void activate(){
    if(user.isActivate()) throw new IllegalArgumentException("이미 활성화 된 유저");
    this.activated = true;
  }

  public void deactivate(){
    if(!user.isActivate()) throw new IllegalArgumentException("이미 비활성화 된 유저");
    this.activated = false;
  }
....
}

어떤 효과가 있을까요?

메서드의 행위를 명확하게 만들어서 '유저를 활성화 한다.' '유저를 비활성화 한다.' 등으로 개발자로 하여금 직관적으로 코드를 이해할수 있습니다.
다음 사람이 나의 프로젝트를 이어 받아서 같이 작업할 때 그사람도 덜 힘들고, 나 또한 적은 질문덕에 덜 힘들다는 것입니다.

개인적 경험

아마 제가 경험 했듯이 서비스 단에서

if(user.isActivate()) throw new IllegalArgumentException("이미 활성화 된 유저");

Setter를 즐겨 사용하셨다면 이런 코드들이 반복 되어 메서드로 묶어본 경험이 있으실 겁니다.
서비스에서 굳이 확인하지 않아도 되는 것을 서비스에서 확인 하느라 중복이 일어나고 이걸 validUserOnActivateOrDeactivate(User user) 이런 식으로 사용했을 겁니다. 그러면 또 다른 서비스에서 해당 서비스의 validUserOnActivateOrDeactivate 메서드를 호출하고 호출 관계가 조금 복잡하게 형성되기 시작하면서 서비스의 호출이 어디로 튈지 예상하기 어려워 유지보수하기 어려운 순간을 만나게 됩니다.

마치며

평소에 Setter를 지양 하면서도 그효과를 정확히는 몰랐는데 이번에 그 효과를 알게되어 궁금점이 풀렸습니다.
앞으로도 Setter를 지양하고 명확한 메서드로 작업해야 겠습니다.
그래도 역시 써야 할때는 서야