😥 문제

Getter와 Setter를 함부로 사용하면 안되는 이유

1. 캡슐화 위반:
   • 내부 구현 노출: Getter와 Setter를 무분별하게 사용하면 객체의 내부 상태가 외부로 노출 됨.
   • 이는 객체의 내부 구현에 의존하게 만들어, 내부 구현이 변경될 경우 외부 코드도 함께 수정해야 하는 문제를 일으킬 수 있음.
   • 무분별한 상태 변경: Setter를 통해 객체의 상태를 외부에서 변경할 수 있게 되면, 객체의 일관성이 깨질 수 있음. 객체의 상태는 객체 스스로가 관리해야 하며, 외부에서 직접 변경하는 것은 바람직하지 않다.
2. 객체의 책임 모호화:
   • 책임의 분산: Getter와 Setter를 통해 객체의 상태를 외부에서 직접 조작하게 되면, 객체의 책임이 분산된다. 이는 코드의 책임 분리가 명확하지 않게 되어 유지보수성과 가독성을 저하시킨다.
   • 비즈니스 로직의 유출: 객체 내부에 있어야 할 비즈니스 로직이 Getter와 Setter를 통해 외부로 유출될 수 있음. 이는 비즈니스 로직의 중복을 초래하고, 코드의 일관성을 해칠 수 있음.
3. 테스트 어려움:
   • 예측 불가능한 상태: Getter와 Setter를 통해 객체의 상태가 변경될 수 있으면, 객체의 상태가 예측 불가능해집니다. 이는 테스트의 복잡성을 증가시키며, 테스트가 신뢰할 수 없게 만듭니다.
   • Mocking 어려움: 테스트 시 Mock 객체를 사용해야 할 경우, Getter와 Setter를 많이 사용하면 Mocking이 복잡해집니다. 이는 테스트 코드의 복잡성을 증가시키고 유지보수를 어렵게 합니다.
4. 코드의 결합도 증가:
   • 의존성 증가: Getter와 Setter를 통해 객체의 내부 상태에 직접 접근하게 되면, 객체 간의 결합도가 증가함. 이는 코드의 변경이 다른 부분에 영향을 미칠 가능성을 높이며, 코드의 유연성을 저하시킴.
   • 변경의 어려움: 내부 구현이 외부로 노출되어 있으면, 객체의 내부 구조를 변경하는 것이 어려워짐.
   • 이는 코드의 유연성을 제한하고, 유지보수를 어렵게 만든다.

좋은 Getter와 Setter 사용 원칙

1. 캡슐화 준수: 객체의 상태는 가능하면 외부에 노출하지 말고, 객체 내부에서 관리해야 함. 필요한 경우에만 Getter와 Setter를 사용하여 상태를 외부에 노출.
2. 비즈니스 로직 포함: Setter 메서드에는 단순히 값을 설정하는 것 외에도 유효성 검사나 비즈니스 로직을 포함시켜 객체의 상태를 올바르게 유지.
3. 불변 객체 사용: 가능하다면 불변 객체(Immutable Object)를 사용하여 객체의 상태가 변경되지 않도록 합니다. 이는 객체의 일관성을 유지하고, 예측 가능한 코드를 작성하는 데 도움됨.
4. 인터페이스 설계: 객체의 상태를 직접 노출하기보다는, 필요한 동작을 수행하는 메서드를 제공하여 객체의 상태를 관리함. 예를 들어, deposit(amount)와 같은 메서드를 제공하여 내부적으로 상태를 변경

결론

Getter와 Setter의 무분별한 사용은 객체 지향 프로그래밍의 핵심 원칙인 캡슐화를 위반하고, 코드의 유지보수성과 가독성을 떨어뜨리며, 결합도를 증가시킨다. 따라서, Getter와 Setter는 꼭 필요한 경우에만 사용하고, 객체의 상태는 객체 내부에서 관리하는 것이 바람직함.

🙌🏻 해결 방법

어노테이션으로 주입하는 Getter와 Setter는 사용하지말고 하자!

🔎 참고 자료

https://colabear754.tistory.com/173