Message Passing

객체가 다른 객체의 필드를 직접 꺼내 읽고 바꾸기 시작하면 경계는 금방 무너집니다. 그 순간 캡슐화는 이름만 남고 한 객체의 내부 표현이 여러 호출자에게 새어 나갑니다. 내부 구조가 조금만 바뀌어도 연쇄적으로 수정해야 하는 코드가 늘어나는 이유가 여기에 있습니다.

Smalltalk 전통은 객체를 독립된 행위 주체로 보고 객체 사이 협력을 메시지 전달로 설명했습니다. 지금은 대부분의 언어가 메서드 호출 문법을 쓰지만 설계 관점은 같습니다. 객체는 남의 데이터를 대신 만지는 구조가 아니라 요청을 받고 자기 책임 안에서 응답하는 협력자라는 생각입니다.

보내는 객체는 수신 객체가 공개한 메서드를 호출합니다. 수신 객체는 현재 상태를 확인하고 필요한 검증과 계산을 수행한 뒤 결과를 반환하거나 다음 협력자에게 또 다른 요청을 보냅니다. 핵심은 호출자가 처리 절차를 세세하게 지시하지 않는다는 점입니다. 무엇을 할지만 요청하고 어떻게 할지는 수신 객체가 책임집니다.

메시지 전달과 직접 데이터 조작의 차이는 책임이 머무는 위치에 있습니다. 메시지 전달에서는 수신 객체가 자기 규칙 안에서 일을 처리하지만, 직접 필드 조작은 그 규칙을 호출자 쪽으로 끌어냅니다. 객체지향다운 협력은 데이터를 공유하는 것보다 책임을 가진 객체끼리 요청을 주고받는 쪽에 더 가깝습니다.

도메인 모델 메서드, 서비스 간 위임, UI 이벤트 처리처럼 객체 간 협력이 핵심인 거의 모든 자리에서 메시지 전달 관점이 유효합니다. 다만 객체를 지나치게 잘게 쪼개면 짧은 메시지가 여기저기 오가면서 흐름이 산만해지고, 디버깅 시 책임의 경로를 따라가기 더 어려워질 수 있습니다.