6장 퍼블릭 인터페이스 설계

6장 관련 이야기 나눈 내용

• 트레이드오프 상황을 보니 설계에 정답은 없다. 어렵다!! 끊임없이 수정하고 검증해봐야 한다. 앞에서 본 예제들은 이상적인 수정이었구나.
• 이번에 소개된 원칙들은 생각보다 적용하기 어려워보인다. 어떻게 활용할 수 있을까? 우선 책임주도설계나 리팩토링으로 코드를 이동시키고, 인터페이스가 이 원칙들을 위반하는지 확인하자. 이때 코드를 보고 원칙을 위반한 것 같다고 접근하더라도, 어떤 조치를 취할 것인지는 캡슐화, 응집도, 결합도를 따져야 한다. 그리고 어떤 결정을 내렸는지 기록으로 남겨두면 나중에 새로 온 사람이 보거나 설계를 개선할 때 활용할 수 있을 것 같다.
• 이름이 의도를 드러내도록 바꾸니 협력을 이해하는데 확실히 도움이 되었다. 협업을 한다면 네이밍 컨벤션을 사용해야할 것.
• 명령 쿼리 분리 패턴을 적용한 자바 api가 떠오른다. Iterator, StringTokenizer 등도 명령 쿼리 분리를 적용해서 변경으로 인한 부수효과를 캡슐화한 것이구나.

퍼블릭 인터페이스의 품질을 높이는 설계

• 최소한의 인터페이스를 가지며, 무엇을 하는지에 집중함. 내부 구현을 노출하지 않음.
• 디미터 법칙, 묻지 말고 시켜라
• 의도를 드러내는 인터페이스
• 명령 쿼리 분리

디미터 법칙

• 내부 구현 노출 방지에 집중하여 결합도를 낮춤
• 도트가 여러개 사용되어 내부 구현을 알 수 있다면 위반
• 객체 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한함
• 의존성 있는 인스턴스에만 메시지를 보내도록 제한 : this, arg, local var 등

묻지 말고 시켜라

• 상태에 대해 묻지 말고 원하는 것을 시켜라
• 자연스럽게 정보 전문가에게 책임을 할당하고 높은 응집도를 얻을 수 있음

의도를 드러내라

• how가 아닌 what을 드러내는 이름
• 동일 작업을 수행하는 여러 메소드들을 하나의 타입 계층으로 묶을 수 있음
• 퍼블릭 인터페이스에는 협력 관련 의도만 표현하여 유연한 협력을 얻음

6장의 캡슐화 개선 시도

• 디 : 내부 구현이 퍼블릭 인터페이스에 드러나지 않도록 로직 이동
• 묻 : 협력을 만들기 위한 스타일
• 의 : 의도를 드러내어 코드 목적을 명확히 하는 커뮤니케이션
• 개인적으로 책임주도설계나 리팩토링에 비해 적용하기 어렵다고 느낌

원칙의 함정

• 디미터 : 하나의 도트를 강제하는 원칙이 아님! 내부 구현을 노출하지 않는 것이 목적. Stream 문법은 여러 도트를 사용하지만 같은 타입을 반환하므로 내부 구현을 노출하지 않음.
• 묻지 말고 시켜라 : 결합도를 낮추려고 로직을 옮겼더니 응집도가 오히려 낮아지는 트레이드오프 상황. 혹은 묻는 대상이 객체가 아닌 자료구조라면 물어볼 수 밖에 없음.

명령 쿼리 분리 원칙

• 쿼리 : 상태를 변경하지 않음
• 상태 변경 : 반환값이 없음. 상태를 변경하므로 부수효과 발생
• 부수효과를 캡슐화하여 제한적으로 참조 투명성 효과를 누릴 수 있음.
• 어쩔 수 없이 물어야할 때, 명령 쿼리를 분리하면 예측 가능한 협력을 만들 수 있다.