유연하고 재사용 가능한 퍼블릭 인터페이스를 만드는 데 도움이 되는 설계 원칙과 기법을 익히고 적용해야 한다.
이런 원칙과 기법들을 살펴보는 것이 이번 장의 주제 !
협력과 메시지
클라이언트-서버 모델
두 객체 사잉의 협력 관계를 설명하기 위해 사용하는 전통적인 메타포이다.
협력 안에서 메시지를 전송하는 객체를 클라이언트, 메시지를 수신하는 객체를 서버라고 부른다.
협력은 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이다.
메시지와 메시지 전송
메시지는 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단이다.
한 객체가 다른 객체에게 도움을 요청하는 것을 메시지 전송 또는 메시지 패싱이라고 부른다.
메시지는 오퍼레이션명과 인자로 구성되며 메시지 전송은 여기에 메시지 수신자를 추가한 것이다.
따라서 메시지 전송은 메시지 수신자, 오퍼레이션명, 인자의 조합이다.
condition.isSatisfiedBy(screening); 수신자 오퍼레이션명 인자
메시지와 메서드
메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저 --> 메서드
메시지와 메서드라는 개념은 실행 시점에 연결되고 컴파일 시점과 실행 시점의 의미가 달라질 수 있다.
이러한 구분이 수신자와 송신자의 결합을 느슨하게 만들 수 있게한다.
퍼블릭 인터페이스와 오퍼레이션
외부에 공개하는 메시지의 집합 --> 퍼블릭 인터페이스
퍼블릭 인터페이스에 포함된 메시지, 수행 가능한 행동에 대한 추상화, 메시지와 관련된 시그니처 --> 오퍼레이션
시그니처
오퍼레이션(또는 메서드)의 이름과 파리미터 목록
인터페이스와 설계 품질
최소한의 인터페이스 + 추상적인 인터페이스의 조건을 만족해야한다.
최소주의를 따르면서도 추상적인 인터페이스를 설계할 수 있는 가장 좋은 방법은 책임 주도 설계 방법을 따르는 것이다.
- 디미터 법칙
- 묻지 말고 시켜라
- 의도를 드러내는 인터페이스
- 명령-쿼리 분리
디미터 법칙
객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한된 원칙
특정한 조건을 만족하는 객체에게만 메시지를 보내야한다.
- this 객체
- 메서드의 매개변수
- this의 속성
- this의 속성인 컬렉션의 요소
- 메서드 내에서 생성된 지역 객체
디미터 법칙을 따르면 부끄럼타는 코드를 작성할 수 있다.
부끄럼타는 코드란?
불필요한 어떤 것도 다른 객체에게 보여주지 않으며, 다른 객체의 구현에 의존하지 않는 코드
묻지 말고 시켜라
디미터 법칙은 "훌륭한 메시지는 객체의 상태에 관해 묻지 말고 원하는 것을 시켜야 한다는 사실"
이런 스타일의 메시지 작성을 장려하는 원칙을 가리키는 용어이다.
밀접하게 연관된 정보와 행동을 함께 가지는 객체를 만들 수 있다.
묻지 말고 시켜라 원칙에 따르도록 메시지를 결정하다 보면
자연스럽게 정보 전문가에게 책임을 할당하게 되고 높은 응집도를 가진 클래스를 얻을 확률이 높아진다.
의도를 드러내는 인터페이스
-
메서드가 어떤 작업을 수행하는 지 이름 짓는다.
-
'어떻게'가 아니라 '무엇'을 하는지 드러내는 것이다.
주의점은 내부 구현 방법을 이름에 드러내면 안된다.
원칙의 함정
디미터 법칙은 하나의 도트(.)를 강제하는 규칙이 아니다
객체의 내부 구조가 노출되는 경우로 한정
결합도와 응집도의 충돌
- 소프트웨어 설계에 법칙이란 존재하지 않는다는 것이다.
- 원칙을 맹신하지 마라.
- 원칙이 적절한 상황과 부적절한 상황을 판단할 수 있는 안목을 길러라.
- 설계는 트레이드오프의 산물이다.
- 소프트웨어 설계에 존재하는 몇 안되는 법칙 중 하나는 "경우에 따라 다르다"
명령-쿼리 분리 원칙
퍼블릭 인터페이스에 오퍼레이션을 정의할 때 참고할 수 있는 지침을 제공한다.
- 프로시저는 부수효과를 발생시킬 수 있지만 값을 반환할 수 없다.
- 함수는 값을 반환할 수 있지만 부수효과를 발생시킬 수 없다.
