안녕하세요! 201 CREATED 팀의 에밀입니다.

피드백은 아래에 이어집니다.

객체에 메세지를 보내라

객체가 가진 정보는 객체가 직접 처리해야 한다. 객체가 가진 정보를 꺼내서 다른 객체에게 처리해 달라고 한다면, 그것은 다른 객체에게로 책임이 분산되기 때문에 캡슐화에 어긋나는 행동이다. 따라서 객체에게 자기가 가진 정보에 대해 로직을 수행하도록 메세지를 보내 요청해야 한다. 객체 내부 메서드에서 객체가 가진 정보에 대한 로직을 수행한다면, 직접 접근이 가능하기 때문에 자연적으로 getter나 setter를 쓸 필요가 없어지는 것이다.

오 정확히 작성해주셨네요!

이를 SRP(Single Responsibility Principle)이라고 하는데요.

결국 객체지향이라는 것의 아주 많은 것이 해당 원리를 지키기 위해 등장했다고 해도 과언이 아닙니다.

이렇게 SRP를 지키게 되면 유지 보수를 할 때 어디를 수정해야할지 빠르게 파악할 수 있죠!

단, Single에 맞게 두 개 이상의 책임을 가지면, 프로그램 복잡도가 높을 수록 하나의 변경에 다른 기능을 디버깅하는 자신을 볼 수 있답니다.

이를 결합도는 낮추고 응집도는 높인다고 말을 하는데요!

말씀하신 캡슐화가 깨지면 결합도가 높아진답니다(서로 다른 클래스들이 강하게 연관되어 있어 하나의 수정이 다른 수정에 영향을 미치게 됩니다)

이 원칙을 가슴속에 지키시면 객체 지향이 한결 친숙할 거에요!

말 그대로 데이터 전달이 목적일 경우에는 사용해도 무방하다. 
예를 들자면 DTO나 VO가 있다. getter 함수를 아예 제공해주는 record라는 문법도 있다. 
이런 경우를 제외하면 getter와 setter는 쓰지 않도록 노력하자.

이미 본인만의 원칙을 세우고 계시군요!

저도 마찬가지로 로직을 담당하는 도메인 객체에게는 setter를 정의하지 않습니다.

setter를 사용하게 되면 (특히나 협업할 때) 예상치 못한 상태 변경으로 인해 다양한 버그의 원인이 된답니다.

객체 초기화 때도 생성자나 정적 팩토리 메서드 패턴을 사용하거나 빌더 패턴을 사용하곤 합니다. (해당 패턴들을 공부하실 필요 없습니다)

getter는 필요에 따라 제한적으로 사용하구요.