[오브젝트: 코드로 이해하는 객체지향 설계/조영호]6장: 메시지와 인터페이스

06/메시지와 인터페이스

객체지향 코드를 얻기 위해서는 클래스가 아니라 객체를 지향해야 한다.

1)협력과 메서드

클라이언트-서버 모델
메시지 전송자 = 클라이언트
메시지 수신자 = 서버

 

메시지와 메시지 전송
메시지: 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통
메시지 전송/메시지 패싱: 한 객체가 다른 객체에게 도움을 요청하는 것
메시지 전송자: 메시지를 전송하는 객체
메시지 수신자: 메시지를 수신하는 객체

메시지 전송 표기법: 수신자.오퍼레이션명.인자
ex) JAVA condition.isSatisfiedBy(screening);

 

메시지와 메서드
condition은 DiscountCondition이라는 인터페이스 타입으로 정의돼 있지만 실제로 실행되는 코드는 인터페이스를 실체화한 클래스의 종류에 따라 달라진다.
condition이 PeriodCondition의 인스턴스라면 PeriodCondition에 구현된 isSatisfiedBy 메서드가 실행될 것이고
condtion이 SequenceCondition의 인스턴스라면 SequenceCondition에 구현된 isSatisfiedBy 메서드가 실행될 것이다.

메서드: 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저
동일한 이름의 변수(condition)에게 동일한 메시지를 전송하더라도 객체의 타입에 따라 실행되는 메서드가 달라질 수 있다.

객체의 메시지 전송은 코드의 의미가 컴파일 시점 = 실행 시점
객체의 메시지와 메서드는 컴파일 시점과 ≠ 실행 시점

 

퍼블릭 인터페이스와 오퍼레이션
퍼블릭 인터페이스: 객체가 의사소통을 위해 외부에 공개하는 메시지의 집합
오퍼레이션(operation): 프로그래밍 언의 관점에서 퍼블릭 인터페이스에 포함된 메시지

오퍼레이션은 수행 가능한 어떤 행동에 대한 추상화다. 오퍼레이션이라고 부를 때는 내부의 구현 코드는 제외하고 단순한 메시지와 관련된 시그니처를 가리키느 경우가 대부분이다.
앞으로 예로든 DiscountCondtion 인터페이스에 정의된 isSatisfiedBy가 오퍼레이션에 해당한다.

메서드는 메시지를 수신했을 때 실제로 실행되는 메서드라고 부른다. SequenceCondition과 PeriodCondition에 정의된 각각의 isSatisfiedBy는 실제 구현을 포함하기 때문에 메서드라고 부른다.
SequenceCondition과 PeriodCondition의 두 메서드는 DiscountCondition 인터페이스에 정의된 isSatisfiedBy 오퍼레이션의 여러 가능한 구현 중 하나다.

 

시그니처
시그니처(signature):오퍼레이션(또는 메서드)의 이름과 파라미터 목록
오퍼레이션은 실행 코드 없이 시그니처만을 정의한 것이다. 메서드는 이 시그니처에 구현을 더한 것이다.
일반적으로 메시지를 수신하면 오퍼레이션의 시그니처와 동일한 메서드가 실행된다.

2)인터페이스와 설계 품질

퍼블릭 인터페이스의 품질

• 디미터 법칙
  협력이라는 컨텍스트 안에서 객체보다 메시지를 먼저 결정하면 두 객체 사이의 구조적인 결합도를 낮출 수 있다. 수신할 객체를 알지 못한 상태에서 메시지를 먼저 선택하기 때문에 객체의 내부 구조에 대해 고민할 필요가 없어진다.
  따라서 메시지가 객체를 선택하게 함으로써 의도적으로 디미터 법칙을 위반할 위험을 최소화할 수 있다.
• 묻지 말고 시켜라
  메세지를 먼저 선택하면 묻지 말고 시켜라 스타일에 따라 협력을 구조화하게 된다. 클라이언트의 관점에서 메시지를 선택하기 때문에 필요한 정보를 물을 필요 없이 원하는 것을 표현한 메시지를 전송하면 된다.
• 의도를 드러내는 인터페이스
  메세지를 먼저 선택하다는 것은 메시지를 전송하는 클라이언트의 관점에서 메시지의 이름을 정한다는 것이다. 당연히 그 이름에는 클라이언트가 무엇을 원하는지, 그 의도가 분명하게 드러날 수밖에 없다.
• 명령-쿼리 분리
  메시지를 먼저 선택한다는 것은 협력이라는 문맥 안에서 객체의 인터페이스에 관해 고민한다는 것을 의미한다. 객체가 단순히 어떤 일을 해야 하는지뿐만 아니라 협력 속에서 객체의 상태를 예측하고 이해하기 쉽게 만들기 위한 방법에 관해 고민하게 된다.
  따라서 예측 가능한 협력을 만들기 위해 명령과 쿼리를 분리하게 될 것이다.

04) 명령-쿼리 분리 원칙

명령-쿼리 분리 운척: 퍼블릭 인터페이스에 오퍼레이션을 정의할 때 참고할 수 있는 지침을 제공한다
루틴: 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈
프로시저: 정해진 절차에 따라 내부의 상태를 변경하는 루틴의 한 종류다.
함수: 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴의 한 종류

프로시저: 부수효과를 발생시킬 수 있지만 값을 반환할 수 없다.
함수: 값을 반환할 수 있지만 부수효과를 발생시킬 수 없다.
프로시저 vs 함수: 프로시와 함수는 부수효과와 반환값 유무 차이

명령(Command)와 쿼리(Query)는 객체의 인터페이스 측면에서 프로시저와 함수를 부르는 또 다른 이름이다.
명령: 객체의 상태를 수정하는 오퍼레이션/객체의 상태를 변경하는 명령은 반환값을 가질 수 없다.
쿼리: 객체와 관련된 정보를 반환하는 오퍼레이션/객체 정보를 반환하는 쿼리는 상태를 변경할 수 없다

 

명령-쿼리 분리와 참조 투명성
참조 투명성이란 "어떤 표현식 e가 있을 때 e의 값으로 e가 나타나는 모든 위치를 교체하더라도 결과가 달라지지 않는 특성"을 의미한다.

f(1) + f(1) = 6
f(1) * 2 = 6
f(1) - 1 = 2

// 계산한 결과 f(1) = 3이라는 결과값을 도출할 수 있었다. 이제 f(1)을 3으로 변경해보자.

3 + 3 = 6
3 * 2 = 6
3 - 1 = 2

이처럼 어떤 값이 변하지 않는 성질을 불변성이라고 부른다.
두 가지 장점일 제공한다.

• 모든 함수를 이미 알고 있는 하나의 결과값으로 대체할 수 있기 때문에 식을 쉽게 계산할 수 있다.
• 모든 속에서 함수의 결과값이 동일하기 때문에 식의 순서를 변경 하더라도 각 식의 결과는 달라 지지 않는다.

함수형 프로그래밍은 부수효과가 존재하지 않는 수학적인 함수에 기반한다. 따라서 함수형 프로그래밍에서는 참조 투명성의 장점을 극대화할 수 있으며 명령형 프로그래밍에 비해 프로그램의 실행 결과를 이해하고 예측하기가 더 쉽다.