오브젝트(조영호) 책 정리 -6-

객체지향 애플리케이션에서 가장 중요한 것은 객체들이 주고받는 메시지다. 애플리케이션은 클래스로 구성되지만 메시지를 통해 정의된다 객체가 수신하는 메시지들이 객체의 퍼블릭 인터페이스를 구성한다. 우리는 유연하고 재사용 가능한 퍼블릭 인터페이스를 만들어야 한다.

 

메시지 : 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단.

 

메시지 전송(패싱) : 한 객체가 다른 객체에게 도움을 요청하는 것

 

메시지를 전송하는 객체 : 메시지 전송자(message sender), 클라이언트

 

메시지를 수신하는 객체 : 메시지 수신자(message receiver), 서버

 

메시지와 메시지 전송

메시지는 오퍼레이션명(operation name)과 인자(argument)로 구성되며, 메시지 전송은 여기에 메시지 수신자를 추가한 것이다.

 

메시지, 오퍼레이션, 메서드 사이의 관계

 

메서드 : 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저. 오퍼레이션의 구현이다.

동일한 이름의 변수(condition)에게 동일한 메시지를 전송하더라도 객체의 타입에 따라 실행되는 메서드가 다를 수 있다.

 

퍼블릭 인터페이스 : 객체가 의사소통을 위해 외부에 공개하는 메시지의 집합

 

오퍼레이션 : 퍼블릭 인터페이스에 포함된 메시지, 객체가 다른 객체에게 제공하는 추상적인 서비스.

오퍼레이션은 수행 가능한 어떤 행동에 대한 추상화이다. 메시지 수신은 메시지에 대응되는 객체의 오퍼레이션을 호출하는 것이다.

 

시그니처 : 오퍼레이션의 이름과 파라미터 목록을 합친 것. 오퍼레이션이나 메서드의 명세를 나타낸 것.

 

좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스라는 조건을 만족해야 한다. 최소한의 인터페이스는 필요한 오퍼레이션만을 인터페이스에 포함한다. 추상적인 인터페이스는 어떻게 수행하는지가 아니라 무엇을 하는지를 표현한다.

 

좋은 퍼블릭 인터페이스를 유지하는 원칙과 기법

• 디미터 법칙
• 묻지 말고 시켜라
• 의도를 드러내는 인터페이스
• 명령-쿼리 분리

디머터 원칙

디미터 원칙은 협력하는 객체 내부 구조에 대한 결합으로 인해 발생하는 문제를 해결하기 위해 제안된 원칙이다. 디미터 법칙은 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라는 것이다. 때로 "오직 하나의 도트(.) 만을 사용해라", "오직 인접한 이웃하고만 말하라"라는 말로 요약된다. 

 

디미터 원칙을 따르기 위해서는 클래스가 특정한 조건을 만족하는 대상에게만 메시지를 전송하도록 해야한다. 클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하도록 프로그래밍해야 한다

• this 객체
• 메서드의 매개변수
• this의 속성
• this의 속정인 컬렉션의 요소
• 매서드 내에서 생성된 지역 객체

디미터 법칙을 따르면 객체가 자기 자신을 책임지는 자율적인 존재로 만들 수 있다.

 

묻지 말고 시켜라

메시지 전송자는 메시지 수신자의 상태를 기반으로 결정을 내린 후 메시지 수신자의 상태를 바꿔서는 안 된다. 훌륭한 메시지는 객체의 상태에 관해 묻지 말고 원하는 것을 시켜야 한다. 상태를 묻는 오퍼레이션을 행동을 요청하는 오퍼레이션으로 대체함으로써 인터페이스를 향상할 수 있다. 

 

묻지 말고 시켜라 원칙을 따르면 밀접하게 연관된 정보와 행동을 함께 가지는 객체를 만들 수 있다.

 

의도를 드러내는 인터페이스

'어떻게'가 아니라 '무엇'을 하는지 나타내도록 인터페이스의 이름을 짓는다. 무엇을 하는지 드러내도록 이름을 짓기 위해서는 객체가 협력 안에서 수행하는 책임에 관해 고민해야 한다. 이는 외부의 객체가 메시지를 전송하는 목적을 생각하게 만들며 결과적으로 협력하는 의도에 부합하는 메서드의 이름을 지을 수 있다.

 

의도를 드러내는 인터페이스를 통해 다양한 타입의 객체가 참여할 수 있는 유연한 협력을 얻을 수 있다. 

 

소프트웨어 설계에 법칙이란 없다

설계는 트레이드오프의 산물이다. 원칙이 현재 상황에 부적합하다고 판단되면 과감하게 원칙을 무시하라. 디미터 법칙과 묻지 말고 시켜라 원칙이 항상 긍정적인 결과로 나오는 것은 아니다. 모든 상황에서 위임 메서드를 추가하면 같은 퍼블릭 인터페이스 안에 어울리지 않는 오퍼레이션들이 공존하게 된다. 결과적으로 객체는 상관없는 책임들을 한꺼번에 떠 안기 때문에 응집도가 낮아진다.

 

명령-쿼리 분리 원칙

어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈을 루틴이라고 부른다. 루틴은 다시 프로시저와 함수로 구분할 수 있다. 프로시저는 정해진 절차에 따라 내부의 상태를 변경하는 루틴이다. 이에 반해 함수는 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴이다. 프로시저와 함수를 명확하게 구분하기 위해 루틴을 작성할 때 다음의 제약을 따라야 한다

• 프로시저는 부수효과를 발생시킬 수 있지만 값을 반환할 수 없다
• 함수는 값을 반환할 수 있지만 부수효과를 발생시킬 수 없다

명령과 쿼리는 객체의 인터페이스 측면에서 프로시저와 함수를 부르는 또 다른 이름이다. 객체의 상태를 수정하는 오퍼레이션을 명령이라고 부르고 객체의 관련된 정보를 반환하는 오퍼레이션을 쿼리라고 부른다. 명령과 쿼리를 분리하기 위해 다음에 규칙을 준수해야 한다.

• 객체의 상태를 변경하는 명령은 반환 값을 가질 수 없다
• 객체의 정보를 변경하는 쿼리는 상태 값을 변경할 수 없다 

명령과 쿼리를 엄격하게 분류하면 객체의 부수효과를 제어하기가 수월해진다.