[Chapter06] 알아서 잘 하는 메서드 vs 놀래키지 않는 메서드

[YJGwon]

내부 구현을 드러내지 않고, 묻지 않고 시키기만 해도 잘 하는 메서드를 만들면 그만큼 클라이언트 입장에서는 메서드의 부수효과를 예측하기 힘들 수도 있을 것 같아요. 캡슐화가 잘 된, 알아서 잘 하는 메서드이면서도 예기치 못한 부수효과를 만들지 않는 메서드를 만드려면 어떻게 해야 할까요? 또는, 이 둘 사이에 균형을 어떻게 찾을 수 있을까요?

[JisuPark-dev]

캡슐화를 하다보면 분명히 그런 문제가 발생할 것 같습니다! 예리한 질문인 것 같아요🧐 제가 생각해보기론

1. 책임을 하나만 가지게 한다.
2. 명령과 쿼리는 분리한다.

요 두가지로 많이 막을 수 있을 것 같습니다.

[JisuPark-dev]

벨: 테스트가 있을 것 같다. 요구사항을 잘 맞추는지 체크할 수 있으니깐. 놀래켰더라도 테스트 케이스를 추가함으로써 놀래키지 않을 수 있을 것 같다.

[JisuPark-dev]

포키: 잘 짜여진 테스트 코드는 훌륭한 문서 역할을 한다고 생각한다. 오히려 코드 내부 구현을 보지 않아도 잘 이해하게 해줄 수 있다고 생각한다. (단, 테스트 코드를 잘 짰다는 가정하에)

• 자바독을 잘 작석해보려고 한다. 객체의 블랙박스화는 캡슐화의 트레이드 오프인 것 같다. - 캡슐화와 같이 갈 수 있는 것들을 작성하는게 방법이 될 수 있을 것 같다.