[객체지향의 사실과 오해] 1. 협력하는 객체들의 공동체 (깊은 독서의 기록)

시너지를 생각하라. 전체는 부분의 합보다 크다
-스티븐 코비-

 

객체지향의 목표는 실세계를 모방하는 것이 아니다. 오히려 새로운 세계를 창조하는 것이다.

객체 지향을 설명할 때 "객체"를 현실 세계의 "사물"로 표현하는 것을 많이 보아왔다. 이는 설계 및 구현하는 실무적인 관점에서는 딱 맞는 표현은 아니지만, 초심자들이 기본 사상을 이해하고 학습하기에는 효과적이다.

책의 초반 부에서는 이 전통적인 관점, "객체지향은 실세계를 모방한다"라는 관점을 빌려 객체지향의 세계를 이해시킨다.

 

먼저, 객체지향에서 가장 중요한 개념 세가지는 역할, 책임, 협력이다.

 

협력은 요청과 응답으로 이루어져있다. 문제를 해결할때 다수의 역할이 필요하기 때문에, 하나의 요청이 또 다른 대상에게로 요청을 유발한다. 따라서 요청은 연쇄적으로 발생한다.

(손님이 커피를 주문(요청)한다 -> 캐셔가 바리스타에게 주문 목록을 전달(요청)한다 -> ...)

요청을 받은 쪽은 책임을 다해 서비스를 제공한다. 즉, 다른 쪽의 요청에 응답한다.

(바리스타가 커피가 제조 완료되었음을 캐셔에게 알려준(응답)다. -> 캐셔가 진동벨을 울려 손님에게 커피가 준비됨을 알린(응답)다-> ...)

요청과 응답을 통해 다른 쪽과 협력을 함으로서, 거대하고 복잡한 문제를 해결할 수 있는 "공동체"를 형성할 수 있다.

 

각각의 사람은 특정한 역할(role)을 부여받는다. 역할이란 협력 안에서 특정한 사람이 차지하는 책임이나 의무를 의미한다.

(손님 역할은 커피를 주문하는 책임, 캐셔는 주문을 받는 책임, 바리스타 역할은 주문된 커피를 제조할 책임)

역할은 책임(responsibility)을 내포한다. 그래서 특정 역할은 특정 책임을 암시한다.

역할과 책임은 협력의 핵심 구성요소이다.

•  책임을 수행하는 방법은 자율적으로 선택할 수 있다. -> 같은 주문을 받더라도 바리스타 역할을 수행하는 사람들 마다 서로 다른 방식으로 요청을 처리할 수 있다. 동일한 요청에 대해 서로 다른 방식으로 응답할 수 있는 능력을 다형성(polymorphism)이라고 한다. -> 나는 이 다형성을 C++ 에서 하나의 클래스를 상속받는 클래스들 내 virtual 키워드를 통해 구현된 함수들이 동작하는 것을 예시로 봤다.
•  한 사람이 동시에 여러 역할을 수행 할 수 있다 -> 캐시어가 바리스타 역할까지 수행하는 것도 가능하다.

 이제 사람을 객체로, 에이전트의 요청을 메시지로, 에이전트가 요청을 처리하는 방법을 메서드로 바꾸면 대부분의 설명을 객체지향의 문맥으로 옮길 수 있다. -> 이 때문에 객체지향을 실세계의 모방이라고 비유한다.

객체지향의 근본 개념은 실세계에서 사람들이 관계맺으며 협력하는 과정과 유사하다. 성실한 객체 시민은 자신에게 주어진 역할과 책임을 다하며 시스템의 더 큰 목적을 이루기 위해 다른 객체와도 적극적으로 협력한다.

 시스템은 역할과 책임을 수행하는 객체로 이루어져있고, 시스템의 "기능"은 객체 간의 연쇄적 요청과 응답의 흐름으로 구성된 "협력"으로 구현된다. 적절한 객체에게 적절한 책임을 할당 하는 것이 객체지향 설계이다. 책임이 불분명한 객체를 만들지 말것.

 

객체지향 애플리케이션의 핵심은 "역할, 책임, 협력"이지만, 객체가 존재하지 않는 객체지향은 의미가 없다. 중심엔 객체가 있다. 협력 공동체의 일원으로 객체는 다음 두 사항을 만족하고 두 사항 속에서 균형을 잡아야한다.

  1. 협력적 : 객체는 다른 객체에 적극적으로 요청하고 응답할 수 있도록 개방되어야한다. 모든 것을 혼자 해결하려는 전지전능한 객체는 자멸한다. 그러나 객체는 다른 객체에게 복종하지 않고, 요청에 응답할 뿐이다. 요청에 응할지도 스스로 결정할 수 있다. 요청과 응답은 "메시지"를 통해 이루어진다.

  2. 자율적 : 스스로 결정하고 책임져야한다.  -> 스스로 결정하는 자율성을 가지기 위해서는 객체 스스로 "상태(State)"와 "행동(Behavior)"을 지녀야한다. 객체에는 분명한 선(private, protected, public)이 있기에 각각 객체는 다른 객체가 "무엇(What)"을 수행하는지는 알 수 있지만, "어떻게(How)" 수행하는지는 알수 없다.(알 필요도 없다고 생각한다.) 

 객체지향은 충분히 개방적이면서 충분히 자율적인 객체들의 공동체를 설계하는게 핵심이다. 과거 전통적 개발 방식에서는 데이터와 프로세스를 엄격히 구분짓지만, 객체지향에서는 데이터(상태)와 프로세스(행동)을 객체에 한데 묶는다. 자율적 객체로 구성된 공동체는 유지보수가 쉽고, 재사용이 용이한 시스템을 구축할 가능성이 높다.

 

객체가 수신된 메시지를 처리하는 방법을 메서드(method)라고 부른다.(나는 여태껏 클래스 내에 존재하는 함수는 메서드라고 부른다고 생각했다. 결과론적으론 맞지만 약간 핀트가 나가있었던거 같다.) 객체지향 프로그래밍 언어에서 메서드는 클래스 내부 함수 또는 프로시저를 통해 구현된다.

?프로시저가 뭐지? -> 트리거에 의해 자동적으로 진행되는 일련의 과정이 트랜잭션이었나 프로시저였나? -> 찾아보고 보충하자

메시지(외부의 요청 표현)와 메서드(요청을 처리하기 위한 구체적 방법)가 분리된 것은 객체의 자율성을 높이는 핵심이다. 이는 캡슐화와도 깊이 관련되어있다.

 

객체 지향이란?

-> 시스템 = 자율적인 객체들의 "공동체"로 바라보고 객체로 시스템을 분할한다.

-> 각각의 객체는 상태, 행위를 가지며 스스로를 책임지는 자율성을 갖는다.

-> 객체는 시스템을 구현하기 위해 다른 객체와 "협력"한다. 협력내 정해진 "역할"을 수행하는데, 각 역할은 "책임"의 집합이다.

 

객체 지향의 중심에는 "클래스"가 아닌, "객체"가 있어야한다. 지나치게 클래스를 강조하면 객체의 캡슐화를 저해하고 클래스간의 결합도를 과하게 높인다. "협력하는 객체들의 공동체"로 보는 관점과 "클래스로 구성된 설계도"로 보는 관점은 매우 다르다.

 객체지향 설계자로서, 첫번째 도전은 "코드를 담는 클래스의 관점"에서 "메시지를 주고받는 객체의 관점"으로 사고의 중심을 전환하는 것이다.

어떤 클래스가 필요한가보다 어떤 객체들이 어떤 메시지를 주고받으며 협력하는지가 중요하다. 클래스는 객체 간의 협력관계를 코드로 옮기는 도구에 불과하다. (-> 책을 읽는 내내 클래스를 대입해 생각했는데, 이 부분은  꽤나 충격이었다. 클래스와 객체는 다르다..!) 클래스들의 정적인 관계가 아닌, 메시지를 주고 받는 객체들의 동적인 관계가 중요하다.

 

객체지향은 객체를 지향하는 것이다. 클래스를 지향하는 것이 아니다.

-------------------------------------------------------------------------------

실제 책은 전문가 답게, 여러 가능성을 열고 쓰여있다. 나는  내 수준에서 이해한대로 조금 단정적으로 옮겨 적으며 이해했다. 

객체지향이란 뭘까 하는 의문이 C++를 사용하며 웹서버를 만들고, 템플릿 메타 프로그래밍을 하며 라이브러리를 만들때 조차 의문으로 계속 남아있었는데, 여러 블로그들에서 추천하는 책이 이 "객체지향의 사실과 오해 -역할,책임,협력 관점에서 본 객체지향"이었다.

항상 책 구독 서비스에는 올라오지 않아 아쉬웠는데, 도서관에 있다고해서 예약까지 걸고 대출해왔다. 

프로덕션 레벨 개발을 경험해보지 못한 학습자의 입장에서 항상 모호했던 객체지향에대한 오해를 조금씩 풀고 싶다.

더불어, 객체지향 프로그래밍을 해본 경험이 많을 수록 이 책을 더 온전히 이해하고 얻어가는 것이 많을 것 같다는 생각이 들었다. 하루에 한 챕터씩 읽어나가며 깊은 독서의 기록을 남기려한다.