객체지향의 사실과 오해 리뷰

 

 

 

 

최근 회사 일과 개인 공부 등으로 바빠 약 3개월간 블로그의 글을 올리지 못했다.

핑계를 대보자면 올리고싶었던 주제의 글은 많았지만 짬(?)이 나지 않았던 것 같다.

 

이 책은 최근 스터디를 하면서 읽었던 책인데 내용이 굉장히 좋은 것 같아 블로그의 글을 작성하기로 마음을 먹었다.

 

그리하여 초보 개발자의 시선에서 조영호님이 쓰신 '객체지향의 사실과 오해' 를 리뷰해보고자 한다.

 

 

01. 협력하는 객체들의 공동체

 

역할과 책임 그리고 협력

• 여러 사람이 동일한 역할을 수행할 수 있다.
• 역할은 대체 가능성을 의미한다.
• 책임을 수행하는 방법은 자율적으로 선택할 수 있다.
• 한 사람이 동시에 여러 역할을 수행할 수 있다.

 

어떠한 객체도 섬이 아니다.

 

 

책의 인용 문구중 '어떠한 객체도 섬이 아니다.' 라는 말이 나오는데

처음에 읽었을 때는 무슨 의미인지 한참 생각했던 것 같다.

 

 

 

내가 느낀 이 글의 의미는 '객체지향 세계에서 객체들은 서로 동떨어진 문자 그대로의 '객체'가 아닌 서로 협력하기 위해서 존재하는 협력을 위한 객체이다' 라는 뜻으로 받아들였다.

 

객체는 그 자체로 자율적이여야 하지만 역설적으로는 협력이 없으면 객체가 아니다 라는 뜻을 내포하고 있는 것 같았다.

 

객체들은 책임이 있고 그 책임들의 집합이 역할이고 역할은 특정 객체만의 고유 역할이 아닌 여러 객체들이 공유할 수 있는 대체 가능성을 의미한다.

 

그리고 그것이 객체지향 패러다임의 중요한 기반을 제공하는 다형성과도 깊이 연관이 있다는 것을 알 수 있다.

 

객체지향의 본질

• 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해서 시스템을 분할하는 방법이다.
• 자율적인 객체란 상태,행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미한다.
• 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.
• 객체는 다른 객체와 협력하기 위해서 메시지를 전송하고, 메세지를 수신한 객체는 메시지를 처리하는데 접합한 메시지를 자율적으로 선택한다.

 

 

이 책에서는 '객체지향의 핵심은 클래스가 아니다. 핵심은 적절한 책임을 수행하는 역할 간의 유연하고 견고한 협력 관계를 구축하는 것이다.' 라고 한다. 즉 중요한 것은 클래스들의 정적인 관계가 아닌 메시지를 주고받는 객체들의 동적인 관계라고 설명한다.

 

흔히 Java를 처음 배울 때 클래스가 곧 객체이며, 중요한 것은 클래스를 설계하는 것이라고 배우는데, 클래스는 객체를 설계하기 위한 도구일 뿐 중요한 것은 소프트웨어의 객체들이 서로 협력하는 관계를 구축하는 것이라고 느꼈다.

 

 

02. 이상한 나라의 객체

 

이 책에서는 '이상한 나라의 엘리스' 의 스토리를 이용하여 객체지향을 설명한다. 모두가 아는 동화의 내용으로 객체지향의 세계를 이해하는 것이 객체지향 패러다임을 받아들이는 것에는 훨씬 거부감이 적었지만, 아쉬웠던 점은 굉장히 추상적이라 받아들이는 개념이 모호했다는 점이다.

 

행동이 상태를 결정

• 상태를 먼저 결정할 경우 캡슐화가 저해된다. 상테에 초점을 맞출 경우 상태가 객체 내부로 깔끔하게 캡슐화되지 못하고 공용 인터페이스에 그대로 노출되버린 확률이 높다.
• 객체를 협력자가 아닌 고립된 섬으로 만든다. 객체가 필요한 이유는 애플리케이션의 문맥 내에서 다른 객체와 협력하기 위해서다. 불행하게도 상태를 먼저 고려하는 방식은 협력이라는 문맥에서 멀리 벗어난 객체를 설계함으로써 자연스럽게 협력에 적합하지 못하는 객체를 창조하게 된다.
• 재사용성이 저하된다. 객체의 재사용성은 다양한 협력에 참여할 수 있는 능력이 나온다. 상태에 초점을 맞춘 객체는 다양한 협력에 참여하기 어렵기 때문에 재사용성이 저하될 수밖에 없다.

 

 

나에게 가장 인상깊었던 파트는 바로 이 파트였던 것 같다. 지금까지 개발을 해오면서 클래스 설계를 할 때 나는 항상 상태를 우선 구현했던 것 같다. 나중에 협력 관계를 구현하면서 초기에 구축했던 상태들로 인해 혼란이 많았었던 것 같다.

 

객체 간의 협력 관계를 고려하여 행동을 적절한 객체에 분배하고 협력에 맞는 상태를 결정하는 것이 올바른 순서라는 것을 깨달았다. 이 책에서 소프트웨어 객체로 구현에 있어 '의인화'라는 개념을 제시하는데 굉장히 와닿았던 것 같다.

 

현실 세계에서의 메뉴판은 메뉴를 직접 골라주지 않는다. 하지만 소프트웨어 객체를 구현할 때는 메뉴라는 객체가 자율적으로 메뉴를 초이스한다. 즉 객체지향 패러다임 세계의 소프트웨어 객체는 현실 세계를 단순히 모방한 것이 아닌 소프트웨어 안에서 제 기능을 할 수 있도록 창조하는 것이다.

 

 

03. 타입과 추상화

 

개념의 세 가지 관점

• 심볼 : 개념을 가리키는 간략한 이름이나 명칭
• 내연 : 개념의 완전한 정의를 나타내며 내연의 의미를 이용해 객체가 개념에 속하는지 여부를 확인할 수 있다,
• 외연 : 개념속에 속한 모든 객체의 집합

 

트럼프에 대입해보면

 

• 심볼 : 트럼프
• 내연 : 몸이 납잡하고 두 손과 두 발은 네모 귀통이에 달려 있는 등장인물
• 외연 : 정원사, 병사, 신하, 왕자와 공주, 하객으로 참석한 옹과 왕비들, 히트잭, 하트 왕과 하트 여왕

 

 

 

객체가 어떤 행동을 하느냐에 따라 객체의 타입이 결정된다. 객체의 타입은 객체의 내부 표현과는 아무런 상관이 없다. 따라서 객체의 내부 표현 방식이 다르더라도 어떤 객체들이 동일하게 행동한다면 그 객체들은 동일한 타입에 속한다.

 

 

행동이 우선이다

 

 

객체의 내부 표현 방식이 다르더라도 어떤 객체들이 동일하게 행동한다면 그 객체들은 동일한 타입에 속한다. 결과적으로 동일한 책임을 수행하는 일련의 객체는 동일한 타입에 속한다고 말할 수 있다.

 

그 객체가 어떤 데이터를 가지고 있는지는 우리의 관심사가 아니다. 그 객체가 다른 객체와 동일한 데이터를 가지고 있더라도 다른 행동을 한다면 그 객체들은 서로 다른 타입으로 분류돼야한다.

 

결론적으로 객체의 타입을 결정하는 것은 객체의 행동일 뿐이다. 객체가 어떤 데이터를 보유하고 있는지는 타입을 결정하는데 아무런 영향도 미치지 않는다.

 

훌륭한 객체지향 설계는 외부에 행동만을 제공하고 데이터는 행동 뒤로 감춰야한다. 이 원칙을 흔히 캡슐화라고 한다.

 

처음 Java와 OOP에 대해서 배울 때 캡슐화의 중요성도 함께 배운다. 사실 이 책을 읽기 전까지 캡슐화를 꼭 해야하는 이유에 대해서 항상 물음표가 있었다. 기껏해야 보안 문제, 유지보수성 정도로 이해했던 것 같다.

 

캡슐화가 잘 될수록 객체는 더 자율적이게되고 자율적일수록 변경에 용이하다.

나 또한 이 책처럼 객체에 대해 비유해보자면, 객체는 '어른'이다.(자율적으로 책임을 지기 때문에..ㅎ)

 

04. 역할, 책임, 협력

 

재판 속의 협력

• 누군가 왕에게 재판을 요청함으로써 재판이 시작된다.
• 왕이 하얀 토끼에게 증인을 부를 것을 요청한다.
• 왕의 요청을 받는 토끼는 모자 장수에게 증인석으로 입장할 것을 요청한다.
• 모자 장수는 입장은 왕이 토기에게 요청했던 증인 호출에 대한 응답이기도 하다.
• 모자 장수는 자신이 알고 있는 내용들을 증엄함으로써 왕의 요청에 웅답한다.

 

 

어떤 등장인물들이 특정한 요청을 받아들일 수 있는 이유는 그 요청에 대한 적절한 방식으로 응답하는데 필요한 지식과 행동 방식을 가지고 있기 때문이다. 그리고 요청과 응답은 협력에 참여하는 객체가 수행할 책임을 정의한다.

 

 

 

 

책임

객체지향의 세계에서는 어떤 객체가 어떤 요청에 대해 대답해 줄 수 있거나, 적절한 행동을 할 의무가 있는 경우 해당 객체가 책임을 가진다고 말한다. 객체지향에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에게 할당하는 것이라고 도 말한다. 이책에서는 객체의 책임을 크게 '하는 것' 과 '아는 것' 으로 분류하고 있다.

 

 

하는 것(doing)

• 객체를 생성하거나 계산하는 등의 스스로하는 것
• 다른 객체의 행동을 시작 시키는 것
• 다른 객체의 활동을 제어하고 조절하는 것

 

아는 것(knowing)

• 개인적인 정보에 관해 아는것
• 관련된 객체에 관해 아는 것
• 자신이 유도하거나 계산할 수 있는 것에 관해 아는 것

 

 

 

역할

역할이 답이다

재판이라는 협력 과정 속에서 하트 왕고 하트 여왕은 판사의 역할을 수행한다. 모자 장수와 요리사, 그리고 엘리스는 증인의 역할을 수행한다. 따라서 판사와 증인이라는 역할을 사용하면 세 가지 협력을 모두 포괄할 수 있는 하나의 협력으로 추상회된다.

 

역할은 협력 내에서 다른 객체로 대체할 수 있음을 나타내는 일종의 표식이다. 협력안에서 역할은 "이 자리는 해당 역할을 수핼할 수 있는 어떤 객체라도" 대신할 수 있습니다. 라고 말하는 것과 같다.

 

 

협력과 추상화

역할의 가장 큰 가치는 하나의 협력 안에서 여려 종류의 객체가 참여할 수 있게 함으로써 협력을 추상화할 수 있다는 것이다. 역할을 이용하면 협력을 추상화함으로써 단순화할 수 있다.

 

 

 

05. 책임과 메시지

 

자율적인 책임

• 객체가 책임을 자율적으로 수행하기 위해서는 객체에게 할당되는 책임이 자율적이여야한다.
• 너무 추상적인 책임은 해당 책임에 협력에 참여한 의도가 명확해지지 않기 때문에 협력의도를 뚜렷하게 표현할 수 있을 정도로 구체적이어야 한다.

 

 

어떻게가 아니라 무엇을

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

 

메시지와 메서드

하나의 객체는 메세지를 전송함으로써 다른 객체에 접근한다. 왕이 모자 장수에게 전송하라는 메세지를 가리키는 '증언하라'라는 메세지를 전송한다. 하얀 토끼 역시 메시지를 전송하는 방법 이외의 다른 방법으로 모자 장수에게 접근할 수 없다. 이 경우에는 하얀 토끼는 송신자 모자 장수는 수신자가 된다.

 

왕이 모자 장수에게 전송하라는 메시지를 가리키는 '증언하라'라는 부분을 메시지이름 이라고한다. 메시지를 전송할 때 추가적인 정보가 필요한 경우 메시지 아규먼트를 통해 추가 정보를 제공할 수 있다.

 

 

 

다형성

다형성이란 서로 다른 유형의 객체가 동일한 메시지에 대해서 사로 다르게 반응하는 것을 의미한다. 좀 더 추가적으로 말해 서로 다른 타입에 속하는 객체들이 동일한 메시지를 수신할 경우 서로 다른 메서드를 이용해 메시지를 처리 할 수 있다는 메커니즘을 가리킨다.

 

다형성은 역할, 책임, 협력과 깉은 관련이 있다. 서로 다른 객체들이 다형성을 만족시킨다는 것은 객체들이 동일한 책임을 공유한다는 것을 의미한다.

 

다형성에서 중요한것은 메시지 송신자의 관점이다. 메시지 송신자의 관점에서 이 객체들이 동일한 책임을 수행한다는 것이다. 즉 송신자의 관점에서 다형적인 수신자들을 구별할 필요가 없으며 자신의 요청을 수행할 책임을 지닌다는 점에 모두 동일하다.

 

 

 

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

휼륭한 객체란 구현을 모른 채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체를 의미한다. 이 것은 객체를 설계할 때 객체 외부에 노출되는 인터페이스와 객체의 내부에 숨겨지는 구현을 명학하게 분리해서 고려해야 한다는 것을 의미한다.

인터페이스와 구현의 분리 원칙이 왜 중요한가? 그것은 소프트웨어는 항상 변경되기 때문이다. 수 많은 객체들이 물고 물리며 돌아가는 객체지향 공동체에서 어떤 객체를 수정했을 때 어떤 객체가 영향을 받는지 판단하는 것은 거의 곡예에 가깝다.

 

객체가 가져야 할 상태와 메서드 구현은 객체 내부에 속한다. 이 부분은 수정하더라도 갹체 외부에 영향을 미쳐서는 안된다. 객체 외부에 영향을 미치는 변경은 객체의 공용 인터페이스를 수정할 때 뿐이다.

객체지향적인 사고 방식을 이해하기 위해서는 다음의 세 가지 원칙이 중요하닥 주장한다. 이 것은 모두 인터페이스에 관련된 것이다.

 

 

1. 좀 더 추상적인 인터페이스
2. 최소 인터페이스
3. 인터페이스 구현 간에 차이가 있다는 점을 인식

 

마치며

이 책을 통해 객체지향의 본질적인 의미에 대해 좀 더 근접하게 다가갈 수 있었다. 그리고 이 책은 한번이 끝이 아니라 두고두고 봐야될 것 같다. 연차가 쌓일수록 아는게 늘어날수록 느끼는 바가 매번 다를 것 같다.