5장. 책임과 메시지

의도는 "메시징"이다. 훌륭하고 성장 가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 커뮤니케이션하는가에 달려있다.
- 앨런 케이

사건에 대한 목격자가 많으면 많을수록 개인이 느끼는 책임감은 적어진다. '책임감 분산(diffusion of responsibility)' 현상으로 군중들 사이로 타인을 도와야 한다는 책임이 분산되어 흩어질 경우 사람들은 애써 자신의 책임을 무시하려고 한다.

이와 달리 자기 혼자 목격한 경우 자신에게 타인을 도와야 하는 책임이 있다고 생각한다.

객체의 세계는 이처럼 명확한 책임과 역할을 지닌 참가자들이 협력에 참여해야 한다는 교훈을 얻을 수 있다. 훌륭한 객체지향의 세계는 명확하게 정의된 역할과 책임을 지닌 객체들이 상호 협력하는 세계다.

역할과 책임이 흐려질수록 도움이 필요한 객체를 도와줄 어떤 협력 객체도 찾지 못하게 된다.

자율적인 책임

객체지향 공통체를 구성하는 기본 단위는 '자율적인 객체'다. 애플리케이션 기능을 구현하기 위해 협력하고, 협력 과정에서 각자의 책임을 다하기 위해 '자율적'으로 판단하고 행동한다.

자율적인 객체

자율성: 자기 스스로의 원칙에 따라 어떤 일을 하거나 자신을 통제해서 절제하는 성질이나 특성

타인의 명령이나 규칙에 따라 판단하고 행동하는 객체는 자율적인 객체라고 부르기 어렵다.

객체지향 설계의 아름다움은 적절한 책임을 적절한 객체에게 할당하는 과정 속에서 드러난다.

적절한 책임은 자율적인 객체를 낳음
자율적인 객체들이 모여 유연하고 단순한 협력을 낳음

따라서 협력에 참여하는 객체가 얼마나 자율적인지에 따라 전체 애플리케이션의 품질을 결정한다.

앨리스의 재판 이야기로 예시를 들어보자.

왕이 모자 장수에게 '증언하라' 라는 요청(메시지)를 보낸 상황

모자 장수가 자율적인 객체인 경우, 어떤 방법으로 증언하는지에는 관심이 없다.
- 증언 방식이나 증언에 필요한 자료는 스스로의 의지와 판단에 따라 자유롭게 선택이 가능한 것
모자 장수가 자율적이지 못한 객체의 경우, 상세한 수준으로 요청해야 한다.
- 1. 목격했던 장면을 떠올려라 / 2. 떠오르는 시간 순서대로 재구성하라 / 3. 말로 간결하게 표현하라
- 증언 방식이나 증언을 어떻게 해야하는지까지 간섭을 하게 된다.
- 모자 장수가 증언하기 위해 선택할 수 있는 자유의 범위를 지나치게 제한하게 된다.

자신의 책임을 수행하기 위해 자신의 의지나 판단력이 아닌 외부 명령에 의존하는 객체는 충분히 자율적이지 못하다.

너무 추상적인 책임

그렇다고, 포괄적이고 추상적인 책임을 선택한다고 무조건 좋은 것은 아니다. 협력의 의도를 명확하게 표현하지 못할 정도로 추상적인 것 역시 문제이다.

만약 위에서 왕이 '증언하라' 라는 요청이 아닌 '설명하라' 라고 했다면 모자 장수는 어떤 설명을 해야하는가?

추상적이고 포괄적인 책임은 더 다양한 환경에서 재사용할 수 있도록 유연성을 제공하지만, 의도를 명확하게 설명할 수 있는 수준 안에서 추상적이어야 한다.

자율적인 책임은 어떻게(how)가 아닌 무엇을(what) 해야하는가 설명한다. 어떻게 응답할 것인지는 객체의 자율성에 맡기는 것임을 명심하자.

메시지와 메서드

메시지

객체는 메시지를 전송함으로써 다른 객체에 접근
메시지-전송 메커니즘은 객체가 다른 객체에 접근할 수 있는 유일한 방법
메시지 송신자와 수신자 사이의 협력이 이루어짐

메시지의 구조는 다음과 같다.

메시지 이름(Message Name): '증언하라'
메시지 인자(Message Argument): 메시지 전송시 추가적인 정보

MESSAGE = MESSAGE NAME(ARGUMENT)
메시지: 증언하라(어제, 왕국)

메시지 전송은 수신자 + 메시지 조합

메시지를 수신받은 객체는 해당 메시지를 처리할 수 있는지 확인
- 메시지를 처리할수 있다 = 해당 메시지에 대한 행동을 수행해야 할 책임이 있다.
메시지의 모양이 객체가 수행할 책임의 모양을 결정

메시지: 모자장수.증언하라(어제, 왕국)

메시지 수신자는 이를 처리하는 방법을 자유롭게 선택할 수 있다. 송신자는 메시지를 제외한 어떤 것도 볼 수 없기 때문이다.

메시지는 객체들이 협력하기 위해 사용하는 유일한 의사소통 수단
객체가 메시지를 수신할수 있다는 것은 해당하는 책임을 수행할 수 있다는 것
메시지 수신자가 어떻게 처리하는지는 자율적으로 선택이 가능하며 송신자는 알 수 없다.

이러한 책임을 기반으로 객체지향 세계가 이루어져야 하는 것을 강조하는 것으로 보인다.

메서드

메시지를 수신한 객체가 내부적으로 메시지를 처리하기 위해 선택하는 방법을 메서드라고 한다.

객체는 메시지를 수신하면 해당 메시지를 처리할 수 있는지 확인
처리가 가능하다면, 주어진 책임을 다하기 위해 메시지를 처리할 방법인 메시드를 선택

객체지향 프로그래밍 언어에서 메서드는 클래스 안에 포함된 함수/프로시저를 통해 구현된다. 따라서 어떤 객체에게 메시지를 전송하면 결과적으로 메시지에 대응되는 특정 메서드가 실행된다.

중요한 점은 '어떻게(how)' 수행될 것인지는 메시지에 담겨져 있지 않다. 오직 '무엇(what)'이 실행되기를 바라는지만 명시된다는 점이다.

다형성

서로 다른 타입에 속하는 객체들이 동일한 메시지를 수신할 경우 서로 다른 메서드를 이용해 메시지를 처리할 수 있는 메커니즘을 가리킨다.

모자 장수가 아닌 다른 객체들도 왕이 전송한 '증언하라'라는 메시지를 처리할 수 있다. 또한, 각 수신자는 자신만의 방법을 선택할 수 있다.

다형성은 역할, 책임, 협력과 깊은 관련이 있다.

각각 다른 객체들이 다형성을 만족한다는 것은 객체들이 동일한 책임을 공유한다는 것
즉, 송신자 관점에서 다형적인 수신자들을 구별할 필요 없이 요청을 수행할 수신자들이 책임을 지님

수신자의 종류를 캡슐화하여 객체들의 대체 가능성을 이용해 설계를 유연하고 재사용 가능하게 만든다. 객체지향 패러다임이 강력한 이유는 다형성을 이용해 협력을 유연하게 만들 수 있기 때문이라는 점을 기억하자.

유연하고 확장 가능하고 재사용성이 높은 협력을 구성하자. 메시지를 기반으로 두 객체 사이의 낮은 결합도가 바로 설계가 핵심인 것이다. 따라서, 설계의 품질을 높이기 위해서는 훌륭한 메시지를 선택해야 한다.

메시지를 따라라

객체지향의 기본 개념은 책임을 수행하는 자율적인 객체들의 협력을 통해 애플리케이션을 구축하는 것

클래스 기반의 객체지향 언어를 사용하는 대부분의 사람들은 객체지향 애플리케이션을 클래스의 집합으로 생각한다. 과연 훌륭한 객체지향 프로그래밍의 목적은 훌륭한 클래스를 창조하는 것일까?

클래스가 코드를 구현하기 위해 사용할 수 있는 중요한 추상화 도구인 것은 사실이지만 객체지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지로부터 나온다. 클래스는 단지 동적인 객체들의 특성과 행위를 정적인 텍스트로 표현하기 위해 사용할 수 있는 추상화 도구일 뿐이다. 중요한 것은 클래스가 아닌 객체다.

그러나 지나치게 객체 자체에 초점을 맞출 경우 협력이라는 문맥은 배제한 채 객체 내부의 데이터 구조를 먼저 생각한 후 데이터 조작에 필요한 오퍼레이션을 나중에 고려하는 경우가 있다.

메시지가 아니라 데이터를 중심으로 객체를 설계하는 방식은 객체의 내부 구조를 객체 정의의 일부로 만들기 때문에 객체의 자율성을 저해한다.

훌륭한 객체지향 설계는 어떤 객체가 어떤 메시지를 전송할 수 있는가와 어떤 객체가 어떤 메시지를 이해할 수 있는가를 중심으로 객체 사이의 협력 관계를 구성하는 것이다.

What/Who 사이클

책임-주도 설계 방법에서 역할, 책임, 협력을 식별하는 것은 애플리케이션이 수행하는 기능을 시스템의 책임으로 보는 것부터 시작되며, 어떤 행위가 필요한지를 먼저 결정한 후 이 행위를 수행할 객체를 결정하는 것이 핵심이다.

이러한 객체 사이의 협력 관계를 설계하기 위한 과정을 What/Who 사이클이라고 한다.

어떤 행위(what, MESSAGE)를 수행할 것인지 결정
누가(who) 그 행위를 수행할 것인지 결정

협력이라는 문맥 안에서 필요한 메시지를 먼저 결정한 후에 메시지를 수신하기에 적합한 객체를 선택한다.

묻지 말고 시켜라 (TDA | Tell, Don't Ask)

메시지를 먼저 결정하고 메시지에 적합한 객체를 선택하는 방식을 따르자.

송신자는 수신자가 어떤 객체인지 모르기 때문에 객체에 관해 캐물을 수 없다.
송신자는 수신자가 어떤 객체인지는 모르지만 자신이 전송한 메시지를 잘 처리할 것이라는 것을 믿고 메시지를 전송하는 것 뿐이다.

이러한 '묻지 말고 시켜라' 스타일은 자율적인 객체들의 공동체라는 사실을 강조한다. 필요한 메시지를 전송하기만 하고 메시지를 수신하는 객체가 스스로 메시지의 처리 방법을 결정하게 하자. 이는 객체를 자율적으로 만들고 캡슐화를 보장하며 결합도를 낮게 유지시켜 주기 때문에 설계를 유연하게 만든다.

또한 메시지를 이해할 수만 있다면 다양한 타입의 객체로 협력 대상을 자유롭게 교체할 수 있어 설계가 좀 더 유연해진다.

인터페이스와 구현의 분리

객체지향적인 사고 방식을 이해하기 위해 세 가지 원칙이 중요하다고 주장한다.

좀 더 추상적인 인터페이스
최소 인터페이스
인터페이스와 구현 간에 차이가 있다는 점 인식

1. 좀 더 추상적인 인터페이스

앞에서 설명한 '증언하라' 라는 추상적인 수준의 메시지를 수신할 수 있는 인터페이스를 제공하면 수신자의 자율성을 보장할 수 있다.

여기서 언급한 추상화는 세부 사항을 제거하고 메시지의 의도를 표현하기 위한 기법이며, 인터페이스는 구체적인 것보다 추상적인 인터페이스를 설계하는 것이 더 좋다.

2. 최소 인터페이스(minimal interface)

간단하게 말하면, 사용할 필요가 없는 인터페이스는 최대한 노출하지 말자는 것이다.

인터페이스를 최소로 유지하면, 내부 동작에 대해 최소한으로 외부에 노출할 수 있다.
- 객체 내부를 수정하더라도 외부에 미치는 영향이 줄어든다.
책임-주도 설계 방법을 따를 때 달성할 수 있다.

메시지를 따르라. 그러면 최소 인터페이스를 얻을 수 있을 것이다.

3. 인터페이스와 구현 간에 차이가 있다는 점 인식

단순히 객체의 외부와 내부를 명확하게 분리하는 것이 중요하다고 강조했었다. 이때 객체의 외부를 공용 인터페이스라고 부른다. 그 객체의 내부는 구현(implementation) 이다.

이 원칙은 별도의 설명을 할 만큼 중요하다고 한다.

구현(implementation)

객체를 구성하지만 공용 인터페이스에 포함되지 않는 모든 것이 구현에 포함된다.

객체의 상태
객체의 행동 (메서드)

객체의 외부와 내부를 분리하라는 것은 객체의 공용 인터페이스와 구현을 명확하게 분리하라는 말과 동일하다.

인터페이스와 구현의 분리 원칙

계속해서 강조하는 내용으로 훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용 할 수 있는 객체를 의미한다.

이러한 훌륭한 객체를 만들기 위해서 인터페이스와 구현의 분리(separation of interface and implementation) 원칙을 통해 객체 외부에 노출되는 인터페이스와 객체 내부에 숨겨지는 구현을 명확하게 분리하고 고려해야 한다는 것이다.

변경사항이 외부로 뻗어 나가는 상황은 객체지향 세계에서 피해야 한다. 객체의 모든 것이 외부에 공개돼 있다면, 아무리 작은 부분을 수정하더라도 파급효과가 객체 공동체의 구석구석까지 파고들 것이다.

객체지향은 내부와 외부를 명확하게 구분하는 객체들로 구성된 협력 공동체다. 객체지향이 좀 더 유연하고 재사용 가능하다고 알려진 이유는 객체의 내부와 외부를 명확하게 구분하기 때문이다. 객체의 외부와 내부를 명확하게 구분한다면 설계가 단순하고 유연하고 변경하기 쉬워질 것이다.

책임의 자율성이 협력의 품질을 결정한다

왜 책임의 자율성을 강조하는 것일까?
객체들이 동일한 목적을 달성하기 위한 협력에서 더 나은 설계라고 말하는 기준은 무엇인가?

책임이 얼마나 자율적인지가 전체적인 협력의 설계 품질을 결정하게 된다.

1. 자율적인 책임은 협력을 단순하게 만든다.

세부적인 사항들을 무시하고 의도를 드러내는 추상화된 하나의 문장으로 표현함으로써 협력을 단순하게 만든다.

2. 자율적인 책임은 외부와 내부를 명확하게 분리한다.

'증언하라'라는 책임은 객체가 자율적으로 증언할 방식을 선택하게 한다. 이는 협력의 양상을 두 가지 관점으로 분리한다.

1) 왕이 모자 장수를 바라보는 외부 관점과 2) 모자 장수가 책임을 수행하는 방법을 표현하는 내부 관점으로 왕은 책임을 어떻게 수행하는지는 관심이 없으며 볼 수 없다. 이는 요청 객체가 몰라도 되는 부분이 객체 내부로 캡슐화되기 때문에 인터페이스와 구현이 분리된다.

3. 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.

모자 장수가 어떻게 증언할 것인지 내부적으로 변경을 한다고 하더라도, 협력 관계에 변동 사항은 발생하지 않는다.

변경의 파급효과가 객체 내부로 캡슐화되기 때문에 두 객체 간의 결합도가 낮아진다는 것이다.

4. 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.

'증언하라' 라는 책임을 할 수 있는 객체라면, 모자장수가 아니더라도 재판을 진행하는데 문제가 없다.

책임이 자율적일수록 협력이 좀 더 유연해지고 다양한 문맥에서 재활용될 수 있다. 설계가 유연해지고 재사용성이 높아진다.

5. 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.

객체가 수행하는 책임들이 자율적이면 자율적일수록 객체의 존재 이유를 명확하게 표현할 수 있다. 이는, 동일한 목적을 달성하는 강하게 연관된 책임으로 구성되기 때문이다.

즉, 책임이 자율적일수록 응집도를 높은 상태로 유지하기 쉬워진다.

정리해보자면,

책임이 자율적일수록

적절하게 '추상화'되며
'응집도'가 높아지고
'결합도'가 낮아지며
'캡슐화'가 증진되고
'인터페이스와 구현이 명확히 분리'되며
설계의 '유연성'과 '재사용성'이 향상된다.

객체지향의 강력함을 누리기 위한 출발점은 책임을 자율적으로 만드는 것이다.

Previous4장. 역할, 책임, 협력 Next6장. 객체 지도

Last updated 1 month ago

Was this helpful?