Ch5. 책임과 메시지

자율적인 책임

자율적인 객체란 스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체

외부의 간섭을 받아선 안된다.

자신의 의지에 따라 증언할 수 있는 자유

객체가 책임을 자율적으로 수행하려면 책임이 자율적이어야 한다. → 책임이 자율적? 뭔소리?

• 자율적인 책임
  • 증언하라
• 상세한 수준의 책임
  • 목격했던 장면을 떠올려라 (난 기억력이 안좋아서 메모를 하는 타입인데..?)
  • 시간의 순서대로 재구성하라 (순서를 편집할 수 없음)
  • 말로 간결하게 표현하라 (난 말솜씨가 안좋아서 서류로 제출하고 싶은데?)

→ 자유의 범위를 지나치게 제한하고 있다. 증언이라는 책임을 수행하는데 왕의 명령에 지나치게 의존적이다.

너무 추상적인 책임

너무 구체적인 것도 문제지만 너무 추상적인 것 역시 문제다.

‘증언하라’가 아닌 ‘설명하라'는 메시지는 모자 장수가 무엇을 설명해야할 지 혼란스럽게 만든다.

어떤 책임이 자율적인지를 판단하는 기준은 문맥에 따라 다르다.

이런 모호함이 객체지향 설계를 난해하면서도 매력적으로 만드는 이유다. → 정답은 없다는 거겠지?

‘어떻게'가 아니라 ‘무엇'을

자율적인 책임은 어떻게(how)가 아니라 무엇(what)을 해야 하는가를 설명한다.

메시지와 메서드

메서드

객체가 수신하는 메시지는 곧 객체가 수행해야할 책임의 모양을 결정한다.

→ 외부에서 접근가능한 메서드는 곧 객체의 책임을 의미

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

메시지를 수신한 객체가 실행 시간에 메서드를 선택할 수 있다는 사실은 객체지향 프로그래밍 언어의 핵심적인 특징이다.

다형성

• 메시지: 무엇을 할 것인지? 객체가 갖는 책임의 모양을 결정
• 메서드: 메시지를 처리하기 위한 방법

다형성이란 서로 다른 유형의 객체가 동일한 메시지에 서로 다르게 반응하는 것

메시지는 ‘무엇'을 실행할 지 명시하지만 ‘어떻게' 실행할 지는 전적으로 객체의 몫이다. 어떻게 처리할 지는 객체가 결정한다. 따라서 다형성을 하나의 메시지와 여러 개의 메서드 사이의 관계로 볼 수 있다.

다형성은 수신자의 종류를 캡슐화한다. 이 메시지를 수행만 할 수 있다면 수신자가 누구든지 상관없다.

유연하고 확장 가능하고 재사용성이 높은 협력의 의미

오직 메시지만으로 객체간 상호 협력이 가능하다.

1. 협력이 유연해진다. 송신자는 수신자가 메시지를 이해한다면 누구라도 상관하지 않는다.
2. 협력 수행방식을 확장할 수 있다. 송신자에 영향 없이 수신자를 교체할 수 있다.
3. 협력 수행방식을 재사용할 수 있다. 협력에 영향 없이 수신자의 자리를 대체할 수 있다.

메시지를 따라라

객체지향의 핵심, 메시지

클래스가 코드를 구현하기 위한 추상화 도구인 것은 사실이지만 객체지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지에서 나온다.

클래스를 정의하는 것이 먼저가 아니라 객체들의 속성과 행위를 식별하는 것이 먼저다.

클래스를 중심에 두는 설계는 유연하지 못하고 확장하기 어렵다.

진정한 객체지향 패러다임으로의 도약은 개별적인 객체가 아니라 메시지를 주고 받는 객체들 사이의 커뮤니케이션에 초점을 맞출 때 일어난다.

객체를 독립된 단위가 아니라 협력이라는 문맥 안에서 생각해야 한다.

(X) 바리스타는 뭘 하는 사람이지? 뭘 알고 있어야 하지? 뭘 할 줄 알아야 하지?

(O) 바리스타는 다른 사람들에게 어떤 서비스를 제공해야 하지?

책임-주도 설계 다시 살펴보기, What-who 사이클

어떤 행위가 필요한지를 먼저 결정한 후에 이 행위를 수행할 객체를 결정해야 한다.

객체를 고립시키고 객체의 책임을 고민하는 것은 옳지 않다.

묻지 말고 시켜라

메시지를 정하기 전까지 객체를 정할 수 없다. 그래서 송신자는 수신자의 내부를 알지 못한다. 이는 관계의 결합도를 떨어뜨리고 수신자의 캡슐화를 증진시킨다.

내부를 알 수 없기 때문에 꼬치꼬치 캐물을 수 없다. 단지 내 메시지를 잘 수행할 것이라 믿는 수 밖에 없다.

이건 당장 코드 작성에도 적용할 수 있겠다고 생각

객체 인터페이스

인터페이스, 메시지가 인터페이스를 결정한다

1. 사용법을 익히기만 하면 내부 구조를 몰라도 쉽게 사용가능하다.
2. 인터페이스를 변경하지 않는다면 내부 구성이나 작동 방식을 변경하는 것이 사용자에게 영향을 미치지 않는다.
3. 대상이 변경되어도 동일한 인터페이스를 제공한다면 아무런 문제 없이 상호작용할 수 있다.

객체간 유일한 소통 방법은 메시지다. 메시지의 목록이 곧 인터페이스다.

공용 인터페이스

외부에 공개되는 인터페이스.

다른 객체들의 메시지를 받기도 하지만 자신에게서 메시지를 받기도 한다.

인터페이스와 구현의 분리

객체 관점에서 생각하는 방법

객체지향 사고방식의 세 가지 원칙

1. 좀 더 추상적인 인터페이스
2. 최소 인터페이스, 책임주도 방식을 한다면 자연스레 따라올 것, 객체가 아닌 메시지에 집중해도 마찬가지
3. 인터페이스와 구현 간에 차이가 있다는 점을 인식

구현(implementation), 인터페이스와 구현의 분리 원칙

훌륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체

중요한 이유: 소프트웨어는 항상 변경되기 때문

어떤 객체를 수정했을 때, 어떤 객체가 영향을 받는지를 판단하는 것은 거의 불가능 → (무도해골표시)

캡슐화 (정보 은닉 information hiding)

객체의 자율성을 보존하기 위해 구현을 외부로부터 감추는 것

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

객체가 자율적이면 협력이 이해하기 쉬워지고 변경에 유연해진다.

1. 자율적인 책임은 협력을 단순하게 만든다.
2. 자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리한다.
3. 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.
4. 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.
5. 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.