05 책임과 메시지 (1) 메시지

01 자율적인 책임

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

적절한 책임이 자율적인 객체를 낳고, 자율적인 객체들이 모여 유연하고 단순한 협력을 낳는다. 따라서 협력에 참여하는 객체가 얼마나 자율적인지가 전체 어플리케이션의 품질을 결정한다.

 

객체가 책임을 자율적으로 수행하기 위해서는 객체에게 할당되는 책임이 자율적이어야 한다.

책임이 자율적이지 않다면 객체가 자율적으로 책임을 수행하기 어렵다.

 

쉽게 설명하자면

요청을 할 때 너무 상세하고 구체적으로 요청을 하면

응답을 받은 객체가 책임을 다하기 위해 자신의 의지나 판단력이 아닌 요청에 구체적인 요청에 의존할 수 밖에 없다.

이 말은, 구체적인 요청을 받은 객체는 자육적으로 책임을 수행할 수 없다는 의미가 된다.

(일반적인 요청 : 점심을 먹어라 → 몇시에, 누구와, 어떤 식사을 할지에 대한 선택은 요청을 받은 객체가 자율적으로 결정한다.

 구체적인 요청 : 12시에 엄마와 비빔밥을 먹어라 → 요청을 받은 객체가 누려야하는 선택의 자유는 훼손된다.(자율성이 제한되었다.))

 

그러나

포괄적이고 추상적인 책임을 선택한다고 해서 무조건 좋은 것은 아니다.

(포괄적이고 추상적인 책임 : 먹어라 → 뭘? 밥을? 커피를? 간식을? 개념을? 뭘?)

 

추상적이고 포괄적인 책임은 협력을 좀 더 다양한 환경에서 재사용할 수 있도록 유연성을 제공하지만

협력에 참여하는 의도를 명확하게 설명할 수 있는 수준 안에서 추상적이야 한다.

 

어떤 책임이 자율적이고 가장 적절한가는 설계 중인 협력이 무엇인가에 따라 달라진다.

이런 모호함이 객체지향 설계를 난해하면서도 매력적인 예술(?)로 만드는 이유다. 🙄  

 

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

 

02 메시지와 메서드

메시지

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

객체가 메시지를 수신할 수 있다는 것은 객체가 메시지에 해당하는 책임을 수행할 수 있다는 것을 의미한다.

객체가 유일하게 이해할 수 있는 의사소통 수단은 메시지뿐이며 객체는 메시지를 처리하기 위한 방법을 자율적으로 선택할 수 있다.

외부의 객체는 메시지에 관해서만 볼 수 있고 객체 내부는 볼 수 없기 때문에 자연스럽게 객체의 외부와 내부가 분리된다.

메서드

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

다형성

서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것을 말한다.

(좀 더 구체적으로 말하면,

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

 

메시지는 '무엇'이 실행될지는 명시하지만 메시지를 '어떻게' 실행할 것인지는 수신자가 결정할 수 있다.

메시지 처리 방법에 관련해서 제약이 없기에, 동일한 메시지라고 하더라도 서로 다른 방식의 메서드를 이용해 처리할 수 있다.

→ 다형성은 하나의 메시지와 하나 이상의 메소드 사이의 관계

 

다형성은 동일한 역할을 수행할 수 있는 객체들 사이의 대체 가능성을 의미한다.

→ 다형성은 수신자의 종류를 캡슐화한다.

 

객체지향 패러다임이 강력한 이유는 다형성을 이용해 협력을 유연하게 만들 수 있기 때문이다.

 

 

✉️  메시지를 따라라

객체지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지로부터 나온다.

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

(클래스는 객체의 속성과 행위를 담는 틀일 뿐이다.)

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

 

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

클래스에 담길 객체들의 공통적인 행위와 속성을 포착하기 위해서는 먼저 협력하는 객체들의 관점에서 시스템을 바라봐야 한다.

 

많은 사람들은 시스템에 필요한 데이터를 저장하기 위해 객체가 존재한다는 선입견을 가지고 있다.

하지만 데이터는 객체가 행위를 수행하는 데 필요한 재료이다.

데이터에 대한 결정을 뒤로 미루고 객체의 행위를 고려하기 위해서는 객체를 독립된 단위가 아니라 협력이라는 문맥 안에서 생각해야 한다.

결국 객체를 이용하는 중요한 이유는 객체가 다른 객체가 필요로 하는 행위를 제공하기 때문이다.

독립된 객체의 상태와 행위에 대해 고민하지 말고 시스템의 기능을 구현하기 위해 객체가 다른 객체에게 제공해야 하는 메시지에 대해 고민해야 한다.

객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 해야 한다.

 

정리하면 협력에 필요한 메시지를 먼저 결정하고 메시지가 결정된 후에 메시지를 수신할 객체를 선택한다.

(수신 가능한 메시지가 모여 객체의 인터페이스를 결정한다. → 이건 뒤에서 다루자)

 

메시지를 결정하는 시점에서 어떤 객체가 메시지를 수신할 것인지를 알 수 없기 때문에 당연히 메시지 송신자는 메시지를 수신할 객체의 내부 상태를 볼 수 없다.

→ 메시지 중심의 설계는 메시지 수신자의 캡슐화를 증진시킨다.

→ 송신자가 수신자의 내부 상태를 미리 알 수 없기에 송신자와 수신자의 관계가 느슨하게 결합된다. (결합도 ↓)

 

👊  메시지를 믿어라. 그러면 자율적인 책임은 저절로 따라올 것이다 !