Getter와 Setter는 왜 쓰지말라는 걸까

제가 일반적으로 알고 있던 지식은 클래스를 생성하고 private로 설계해두고 getter와 setter를 사용해서 값을 갖고오거나 값을 변경하게된다면 private로 설정한 의미가 없게되고 캡슐화를 지킬 수 없게 되기때문에 지양하는 것으로 알고있었습니다!

다른 객체들로 책임이 분산된다.

예를 들어서, Car 라는 클래스를 만들고 name 이라는 차 이름에 대한 정보를 갖고있는 필드를 생성했다고 할때 name이라는 정보를 다른 클래스로 가져가서 조회하거나 수정하게된다면, Car가 할일을 다른 클래스에서 하게되는 것이다.
이렇게 구조가 구현되고 만약 Car의 구조가 변경된다면 그 객체의 일을 대신 해주는 모든 코드를 수정해야 한다.

Tell, Don't Ask

그럼 Getter와 Setter를 쓰지 않고 어떻게 구현하나...
물어보지말고 시켜라 즉 값을 묻지 말고 값으로 가공된 정보를 돌려달라고 시키는 것이다.
예를 들어서 Car 클래스의 name의 길이가 5이하인지를 확인하고 싶다면, name값을 갖고와서 비교하는 것아닌 Car에게 name의 길이가 5이하인지를 물어보고 그 결과를 반환받는 것이다.

꼭 사용하지 말아야 하나?

Getter와 Setter의 사용을 지양한다면 Tell, Don’t Ask(TDA) 원칙을 지키면서 코딩을 진행해야 한다. 하지만 getter를 사용하지않고 구현하는 것은 쉽지 않았습니다.
구현을 어떻게든 해냈다고 해도 테스트 과정에서 캡슐화된 정보를 확인하는 것은 쉽지 않았습니다.
그래서 공부해 보던 중에 당당하게 getter를 사용해도 된다라는 블로그를 찾게되었고 학습해 봤습니다.
만약 이름을 출력해야되는 프로그램에서 이름을 캡슐화해서 사용한다면 로직이 불편해질것이고 결국 캡슐화가 깨지지 않는이상 프로그램에서 이름을 보여줄 수 없을 것입니다.
이는 특정 조건에 따라서 getter의 사용을 생각해 봐야한다는 뜻입니다.
저는 그래서 저만의 규칙을 만들고자 했습니다.
getter는 확실히 지양하는 편이 좋다. 하지만 프로그램의 기능에 따라 사용될 수 있다.
프로그램의 기능 요구 사항이 특정한 값을 보여주어야 한다면 getter를 사용해도 캡슐화가 깨졌다고 생각되지않는다.
때문에 요구 사항을 보고 판단하자.
라고 정하게 되었습니다.