협력과 메세지

앞선 포스팅들에서 책임에 관련된 이야기를 계속해서 해왔다.

객체지향에는 또 설명해야할 중요한 개념이 존재하는데 "협력" 과 "메세지" 이다.

이미 앞선 포스팅에서 지겹게 설명했다고 생각할 수도 있지만

이제는 이해를 하기 위해서 현실세계로 잠깐 저 내용을 끌고 와볼까 한다.

 

이 포스팅은 대부분의 내용이 조영호님의 "오브젝트" 를 읽고 느낀점을 생각으로 정리한 글입니다.

본문 제일 아래에 책 링크가 달려있습니다.

협력과 메시지

개인적으로 이 둘은 떼놓고 설명하기가 힘들다고 생각한다.

과연 이 추상적인 개념은 객체지향 세계에서 어떻게 설명할 수 있을까?

 

가장 쉽게 설명할 수 있는건 Client - Server Model 로 설명하는 것이다.

Client 는 Server 에 Request(요청) 을 보내고

Server 는 요청에 대한 동작을 수행한 뒤 Response(응답) 을 보내준다.

이걸 협력과 메세지의 개념으로 다시 재해석 해보면

 

Client 는 Server 에 특정 행위에 대해 Message(Request) 를 보내며 협력을 요청한다.

Server는 Client 의 Message(Request) 를 받은 뒤 협력에 대한 동작을 수행한다.

 

즉, 객체지향의 세계가 단방향으로 구축되는 이유 중 하나이다.

협력에 대한 요청과 필요한 메세지 그리고 협력에 대한 동작 수행 이것이 객체들이 세계를 이루는 방법이다.

하지만 하나의 트랜잭션 (여기서 트랜잭션은 하나의 협력에 대한 동작을 의미) 에서는 클라이언트와 - 서버가 정해져 있을 수 있지만

아래와 같은 상황에서는 트랜잭션마다 클라이언트가 되거나, 서버가 될 수도 있다. 

 

빨간 원 안에서의 Customer 는 

Seller 와의 관계에서는 Server 가 되고

Store 와의 관계에서는 클라이언트가 된다.

 

요점은, 객체세계는 오로지 협력과 메세지로 구성된다는 것이다.

Message

메세지는 조금 더 딥다이브하게 다룰 필요가 있어 좀 더 자세하게 설명하려고 한다.

위의 그림을 보면 알겠지만 메세지는 객체지향에서 협력을 구성하기 위한 유일한 수단이다.

즉, 협력이 존재한다면 불가피 하게 수신자와 송신자가 생기게 된다는 것이다.

 

객체지향 세계에서는 아래와 같이 송신자와 수신자를 구분한다.

다른 객체에게 도움을 요청하기 위해 메세지를 전송하는 객체를 "메세지 전송자" 라고 부른다.

여기서 다른객체에게 도움을 받기 위해 메세지를 보내는 것을 "메세지 전송" 이라고 한다.

반대로 협력을 하기 위해 메세지를 수신하는 객체는 "메세지 수신자" 라고 불린다.

메세지는 아래와 같이 "오퍼레이션 명" 과 "인자" 그리고 "메세지 수신자" 로 구성될 것이다.

즉, 도움을 요청하는 메세지는 위와 같은 구성을 가지고 있다.

 

다소 딱딱했더라도 이해해주길 바란다.

아래 과정을 설명하기 위한 불가피한 과정이다.

Method

메소드란 무엇일까?

객체가 하는 행위?

객체가 외부에 제공하는 인터페이스?

 

일단 DiscountCondition 이 아래와 같은 구조를 지녔다고 해보자.

DisCountValidator 는 DiscountCondition 에 할인을 만족하는지를 확인하기 위해

메세지를 보내며 협력을 요구하고 있다.

우리는 컴파일 시점에 어떤 DiscountCondition 이 실행될지 알 수 없다.

즉, 런타임 시점에서야 어떤 DiscountCondition 의 isSatisfiedBy 오퍼레이션이 실행되는지 알 수 있는데

우리는 이처럼 메세지를 수신했을때 실제로 실행되는 함수를 "메소드" 라고 한다.

 

이게 엄청 중요한 개념이라고 생각하는데

우리는 실행되는 시점과 컴파일 시점에 의미가 다를 수도 있다는 것을 알아채야 한다.

즉, 전통적인 방식은 컴파일 시점과 런타임이 다르기 때문에 

컴파일 시점에 더더욱 알아야 하는 정보가 많이 존재했다.

 

즉, 상대가 어떤 것을 가지고 있는지 알고 호출하는 것과

어떤 객체가 받을지는 모르지만 협력을 위해 메세지를 전송하는 것은 차원이 다른 것이다.

즉, 알아야하는 정보의 양이 다르다.

 

이부분이 잘 이해가지 않는다면,

내 포스팅 중 응집도와 결합도 관련된 부분을 읽고 오길 바란다.

아니면 다른 포스팅을 읽어도 좋다

https://devroach.tistory.com/58?fbclid=IwAR27S7uQcX-rKOG9tf2ZJOJdiQcgKhnANnORhPzmmCrPs49OXLKWgGga5rs 

응집도와 결합도

 

여하튼, 이처럼 메세지를 통해 우리는 메세지 전송자와 수신자가 느슨한 결합구조를 가질 수 있도록 만든다.

퍼블릭 인터페이스

즉, 그렇다면 퍼블릭 인터페이스란 무엇일까?

바로 객체가 협력구조를 이루기 위해 외부에 제공하는 메세지의 집합이다.

 

메세지의 집합 안에 있는 메세지를 "오퍼레이션" 이라고 부른다.

즉, 오퍼레이션이란 특정 행동에 대한 추상화이다.

그리고 그 추상화된 내용이 실제로 실행됬을때의 코드가 "메소드" 이다.

참, 내가 적고도 복잡하다는 생각이 드는데 

즉, 쉽게말하면 isSatisfied 는 "오퍼레이션" 이다.

만약, PeriodCondition 의 isSatisfied 가 실행됬다면

PeriodCondition 의 isSatisfied "코드" 는 "메소드" 이다.

그래서 우리는 "메소드" 를 호출하는 것이 아니라 "오퍼레이션" 을 호출하는 것이 좀더 정확한 표현이다.

 

정리하며

음 오늘 내용은 어쩌면 복잡하다고 느껴질 수 있다.

크게 정리하자면, "메세지 전송" 과 "메소드 호출" 이 알아야 하는 정보의 차이

즉, 알아야 하는 정보의 차이는 결합도 에 큰 영향을 끼친다.

 

오늘은 내용이 추상적이라

남이 이해하기 쉽게 설명한 것인지 잘 모르겠다.

이해가 안간다면 안간 부분에 대한 피드백을 남겨주면 좋겠다.

좀 더 설명을 보완하고 싶다.

 

 

조영호님의 오브젝트

http://www.yes24.com/Product/Goods/74219491

오브젝트 - YES24