5장. 책임과 메시지

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

[ 자율적인 책임 ]

요청을 처리하기 위해 객체가 수행하는 행동을 책임이라고 한다. 따라서, 자율적인 객체란 "스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는" 객체를 의미한다.

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

이전 왕과 모자 장수 이야기를 통해 이해하기

모자 장수는 왕의 요청을 받아야만 책임을 수행하기 시작하겠지만, 증언 방식이나 증언에 필요한 자료는 스스로의 의지와 판단에 따라 자유롭게 선택할 수 있다.

• 협력에서 모자 장수는 왕에게 증언할 책임은 있지만 증언을 위한 구체적인 방법이나 절차에 대해서는 최대한의 자유를 누린다.

• 증언이라는 책임만 완수할 수 있다면 나머지 구체적인 방법이나 절차는 모자 장수가 자유롭게 선택하도록 허용한다.

너무 추상적인 책임

책임이 수행 방법을 제한할 정도로 너무 구체적인 것도 문제지만 협력의 의도를 명확하게 표현하지 못할 정도로 추상적인 것 역시 문제다.

추상적인 상황을 설명하기 위해 이야기를 잠시 바꿔보자.

"모자 장수는 왕과 협력하기 위해 증언 대신 "설명하라" 라는 책임을 수행한다."

여기서 모자 장수는 "설명" 이라는 추상적 단어에 휩쓸려 무엇을 설명해야 할지 모른다.

추상적이고 포괄적인 책임은 재사용과 유연하게 사용할 수 있는 축복이 있지만, 책임은 협력에 참여하는 의도를 명확하게 설명할 수 있는 수준 안에서 추상적이어야 한다.

예시

흔히 객체지향을 프로그래밍을 하게 되면 "getter & setter 를 지양하라" 라는 말을 얼핏 들을 수 있다.

이는 다른 이유도 존재하지만, setter 메서드가 굉장히 추상적이고 포괄적인 행위를 제공하고 있기 때문이기도 하다.

만약, Money 의 금액을 차감하는 경우라면? Money 의 금액을 증가 시킨다면 어떨까?

우리는 두 가지 행위를 하나의 메서드인 setValue() 로 사용한다. 이 것이 바로 "너무 추상적인 책임"에서 짚고 넘어가야 할 문제인 것이다.

되도록 이 행위를 제공할 때 명확하게 제공하자.

public class Money {
    
    private Long value;

    public Money(Long value) {
        this.value = value;
    }

    public Long getValue() {
        return value;
    }

    public void setValue(Long value) {
        this.value = value;
    }
}

상세한 수준의 책임은 증언이라는 협력의 최종 목표는 만족 시킬지 몰라도 모자 장수가 누려야 하는 선택의 자유를 크게 훼손하고 만다.

정리

왕이 모자 장수에게 증언하라고 명령 하는 것은 "무엇" 을 해야 하는지 의미한다.

반대로, 모자 장수가 스스로의 내용으로 증언을 하는 행위는 "어떻게"에 해당한다.

이 "무엇"은 다른 객체가 협력하면서 보내는 메시지이고, "어떻게"는 객체 스스로 구현하는 내용이 되며 위 모자 장수에 이야기를 빗대어 보자면 모자 장수는 본 사실을 토대로 증언을 해도 되겠지만 거짓을 해도 된다.

또한, 자신이 머릿속으로 기억하는 내용을 되뇌이며 증언을 해도 되고, 핸드폰에 기록물들을 읽으면서 증언을 해도 된다. 이토록 무엇을 할지만 정해져있을 뿐 어떻게 하는 것은 관심사가 아니다.

프로그래밍 관점에서 보면 "무엇"은 공개된 인터페이스 스펙이고, "어떻게"는 인터페이스의 구현 메서드이다.

[ 메시지를 따라라 ]

What/Who 사이클

What/Who 사이클은 어떤 객체가 필요한지를 생각하지 말고 어떤 메시지가 필요한지를 먼저 고민하라고 조언한다.

• 메시지를 결정하기 전까지는 객체에 관해 고민하지 말아야한다.

• 일단 메시지가 결정된 후에야 이 메시지를 처리할 객체를 선택한다.

클래스는 단지 동적인 객체들의 특성과 행위를 정적인 텍스트로 표현하기 위해 사용할 수 있는 추상화 도구일 뿐이다.

클래스를 먼저 작성하는 것이 아니라 객체들의 속성과 행위를 식별하는 것이 우선 되어야 한다.

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

객체가 다른 객체의 상태를 묻는다는 것은 메시지를 전송하기 이전에 객체가 가져야 하는 상태에 관해 너무 많이 고민하고 있었다는 증거다.

고민을 연기하라.

묻지말고 시켜라.

정리

상호 협력 관계에서 요청하는 행위는 "메시지" 이고, 수신자 입장에서 처리하는 행위는 "메서드"라고 했다.

이 메시지는 받는 사람이 누군지 모르고 보내는 사람은 당연히 잘 처리될 것 이라는 가정하에 메시지를 보내게 된다.

예를 들어, 우리가 은행에 입금 하는 행위는 받는 은행이 우리든 신한이든 하나든 국민이든 상관 없이 우리는 입금하는 행위에 집중하여 메시지를 보낸다.

수신자가 농협일 경우 처리하는 메서드를 활용할 것이고 이렇게 수신자가 누구인지는 송신자는 알 필요가 없다.

하지만, 송신자가 수신자의 정보를 일일히 다 알고 있거나, 농협 은행만의 정보를 물어보는 메시지는 설계해서는 안된다.

만약, 송신자가 수신자의 정보를 모두 알고 있다면 수신자의 정보를 이용해서 여러가지 행위를 하게 될텐데 그 정보가 바뀌게 될 경우 우리는 변경 사항에 취약해지게 된다.

그러니 우리는 더욱 더 메시지에 의존해서 전적으로 믿고 협력해야 한다.

[ 인터페이스 구현의 분리 ]

사적인 비밀의 캡슐화

객체를 자율적인 존재로 바라보는 것은 결국 객체의 내부와 외부를 엄격하게 분리한다는 것을 의미한다.

• 객체의 내부는 자신의 의지에 따라 변경하고 조작할 수 있는 비밀을 가지고 있다.

• 객체의 외부는 객체가 의지하고 접근할 수 있는 공용 인터페이스를 가진다.

• 어떤 것도 동시에 객체의 내부와 외부에 포함할 수 없다.