[서평] 객체지향의 사실과 오해

저의 돈으로 직접 사서 직접 완독 해본 후 써보는 후기입니다. 따라서 장점은 장점대로 칭찬할 것이며, 단점은 단점대로 언급할 것입니다.

 

객체지향의 사실과 오해

저자 : 조영호

출판 : 위키북스

발매 : 2015.06.17

<읽은 기간>

2021/01/17 ~ 2021/02/09

​

<리뷰 순서>

1) 책의 표지

2) 단원별 요약

3) 읽은 소감

 

우선 저의 글의 앞부분만 보는 분들을 위해 먼저 간단히 3가지에 대해 답해보겠습니다.

​

Q 객체지향의 사실과 오해를 읽기 전에 필요한 수준/ 지식은?

=> 이 책은 코드가 없는 책이다. 물론 7장에서 JAVA코드가 아주 일부분(다 합치면 2장 정도?) 나오지만, JAVA를 몰라도 다른 객체지향 언어를 안다면 무리가 없는 내용이다. 이런 면에서 범용성이 좋은 책이 분명하다. 하지만 객체지향 언어를 하나 정도는 다룰 줄 알아야 책의 내용을 원활하게 이해할 수 있다.

 

Q 이 책을 읽어야 할 필요성, 어디에 도움이 될까?

=> 나처럼 객체지향의 근본이 궁금한 사람들에게 추천한다. 객체지향이란 무엇인가?? class인가?? 문장에서 알 수 있듯 객체를 지향한다는 말인 것 같은데... 객체는 무엇이란 말인가?? 또 이 객체를 지향한다는 의미가 코드를 설계할 때 어떤 영향을 준다는 것 인가?? 등등 다양한 의문이 OOP언어들을 공부하다 보면 자연스럽게 생긴다. 이러한 의문점들에 대한 갈증을 이 책이 해결해주는 것 같다.

 

Q 이 책을 읽은 후 추후 공부는?

=> 나 같은 경우 C++을 아직 더 공부해봐야 하기 때문에 아직 JAVA에 대한 공부 계획은 내년으로 잡아둔 상태이다. 하지만 객체지향의 정수를 느껴보고 싶은 사람이라면 JAVA공부는 필수라 생각한다. 만약 JAVA를 접해본 분들이라면, design pattern이나, 테스트 주도 계발 등 설계에 관한 공부 또한 도움이 될 것 같다.

 

추가로 이책을 쓰신 조영호 님의 신간인 object 라는 책이 2019년도에 나왔다. 그책또한 평이 좋으며, 실질적인 구현에 관한 부분을 배운는 책이라 한다. 그책또한 내가 향후 JAVA를 공부한후, 읽어보고 수기를 작성할것을 약속하겠다.

 

1. 책의 표지

일단 표지가 너무 마음에든다. 딱딱한 전공책의 인상을 주지는 않지만, 부드러우면서 깔끔한 이미지를 선사한다.

책은 내용이 가장 중요하지만, 사실 표지가 구리면 이상하게 눈이 안가는것은 사실이다.

애당초 유명한 명성의 책들이야 인터넷에서 정보를 미리 얻어 후기를 보고 구매하지만, 모르는 분야에서는 눈에 확 들어오는 디자인의 책을 먼저 집어보기 마련이다. 깔끔하면서 이쁜 디자인을 칭찬해주고 싶다.

 

​

2. 단원별 구성

목차

1) 협력하는 객체들의 공동체

2) 이상한 나라의 객체

3) 타입과 추상화

4) 역할, 책임, 협력

5) 책임과 메시지

6) 객체 지도

7) 함께 모으기

8) 부록A

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

시너지를 생각하라. 전체는 부분의 합보다 크다.
Stephen R. Covey

 

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

 

● 역할과 책임

역할은 어떤 협력에 참여하는 특정한 사람이 협력 안에서 차지하는 책임이나 의무를 의미한다. 특정한 역할은 특정한 책임을 암시한다. 역할과 책임은 협력이 원활하게 진행되는 데 필요한 핵심 구성 요소이다.

 

역할에 적합한 책임을 수행한다는 사실은 몇가지 중요한 개념을 제시한다.

- 여러 사람이 동일한 역할을 수행할 수 있다.

- 역할은 대체 가능성을 의미한다.

- 책임을 수행하는 방법은 자율적으로 선택할 수 있다.

- 한 사람이 동시에 여러 역할을 수행할 수 있다.

 

● 상태와 행동을 함께 지닌 자율적인 객체

흔히 객체를 상태(state)와 행동(behavior)을 함께 지닌 실체라고 정의한다. 이 말은 객체가 협력에 참여하기 위해 어떤 행동을 해야 한다면 그 행동을 하는 데 필요한 상태도 함께 지니고 있어야 한다는 것을 의미한다.

 

객체의 자율성은 객체의 내부와 외부를 명확하게 구분하는 것으로부터 나온다. 객체의 사적인 부분은 객체 스스로 관리하고 외부에서 일체 간섭할 수 없도록 차단해야 하며, 객체의 외부에서는 접근이 허락된 수단을 통해서만 객체와 의사소통해야한다. 객체는 다른 객체가 '무엇(what)'을 수행하는지 알 수 있지만 '어떻게(how)' 수행하는지에 대해서는 알 수 없다.

 

● 협력과 메시지

객체지향의 세계에서는 오직 한 가지 의사소통 수단만이 존재한다. 이를 메시지라고 한다.

 

● 객체지향의 본질

- 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법이다.

 

- 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미한다.

 

- 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합이다.

 

- 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택한다.

 

2. 이상한 나라의 객체

객체지향 페러다임은 지식을 추상화하고 추상화한 지식을 객체 안에 캡슐화함으로써 실세계 문제에 내재된 복잡성을 관리하려고 한다. 객체를 발견하고 창조하는 것은 지식과 해동을 구조화하는 문제다.
Rebecca Wirfs-Brock (1990)

 

● 상태는 특정 시점에 객체가 가지고 있는 정보의 집합으로 객체의 구조적 특징을 표현한다. 객체의 상태는 객체에 존재하는 정적인 프로퍼티와 동적인 프로퍼티 값으로 구성된다.

 

● 행동이란 외부의 요청 또는 수신된 메시지에 응답하기 위해 동작하고 반응하는 활동이다. 행동의 결과로 객체는 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달할 수 있다. 객체는 행동을 통해 다른 객체와의 협력에 참여하므로 행동은 외부에 가시적이여야 한다.

 

● 객체는 자율적인 존재이다. 객체지향의 세계에서 객체는 다른 객체의 상태에 직접적으로 접근할 수도, 상태를 변경할 수도 없다. 자율적인 객체는 스스로 자신의 상태를 책임져야 한다.

 

● 행동이 상태를 결정한다.

객체의 상태는 저절로 변경되지 않는다. 객체의 상태를 변경하는 것은 객체의 자발적인 행동뿐이다.

 

● 현실 세계의 객체와 객체지향 세계의 객체 사이에는 중요한 차이점이 있다. 현실과 달리 객체지향의 세계에서 모든 객체는 자신의 상태를 스스로 관리하는 자율적인 존재다.

 

● 객체는 상태를 캡슐 안에 감춰둔 채 외부로 노출하지 않는다. 객체가 외부에 노출하는 것은 행동뿐이며, 외부에서 객체에 접근할 수 있는 유일한 방법 역시 행동뿐이다.

 

● 객체의 행동을 유발하는 것은 외부로부터의 전달된 메시지지만 객체의 상태를 변경할지 여부는 객체 스스로 결정한다. 사실 객체에게 메시지를 전달하는 외부의 객체는 메시지를 수신하는 객체의 상태가 변경된다는 사실조차 알지 못한다.

 

● 상태를 먼저 결정하고 행동을 나중에 결정하는 방법은 설계에 나쁜 영향을 끼친다.

- 상태를 먼저 결정할 경우 캡슐화가 저해된다.

- 객체를 협력자가 아닌 고립된 섬으로 만든다.

- 객체의 재사용성이 저하된다.

 

● 객체지향 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후 행동을 수행할 객체를 선택하는 방식으로 수행된다. 행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다

 

3. 타입과 추상화

● 객체란 특정한 개념을 적용할 수 있는 구체적인 사물을 의미한다. 개념이 객체에 적용되었을때 객체를 개념의 instance라고 한다.

 

● 분류란 객체에 특정한 개념을 적용하는 작업이다. 객체에 특정한 개념을 적용하기로 결심했을때 우리는 그 객체를 특정한 집합의 멤버로 분류하고 있는 것이다.

 

● 데이터 타입은 메모리 안에 저장된 데이터의 종류를 분류하는데 사용하는 메모리 집합에 관한 메타데이터이다. 데이터에 대한 분류는 임시적으로 어떤 종류의 연산이 해당 데이터에 대해 수행될 수 있는지를 결정한다.

 

● 다형성이란 동일한 요청에 대해 서로다른 방식으로 응답할 수 있는 능력을 뜻한다.

 

● 두 타입간에 일반화/특수화 관계가 성립하려면 한 타입이 다른 타입보다 더 특수하게 행동해야 하고 반대로 한 타입은 다른 타입보다 더 일반적으로 행동해야한다.

 

● Type은 추상화다. 타입을 사용하면 동적으로 변하는 객체에 상태를 정적인 관점에서 표현할 수 있다. 결국 타입은 시간에 따른 객체의 상태 변경이라는 복잡성을 단순화할 수 있는 효과적인 방법이다. 이러한 타입을 구현하는 방법이 class이다

 

4. 역할, 책임, 협력

우리 모두를 합친 것보다 더 현명한 사람은 없다.
Ken Blanchard

 

● 객체지향에 갓 입문한 사람들의 가장 흔한 실수는 협력이라는 문맥을 고려하지 않은채 객체가 가져야할 상태와 행동부터 고민하기 시작한다는 것 이다.

 

● 객체지향 설계는 협력에 참여하기 위해 어떤 객체가 어떤 책임을 수행해야하고 어떤 객체로부터 메시지를 수신할 것인지를 결정하는것으로부터 시작된다.

 

● 객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소트웨어 객체에 할당하는 것이다. 책임을 어떻게 구현할 것인가 하는 문제는 객체와 책임이 제자리를 잡은 후에 고려해도 늦지 않다. 객체와 책임이 이리저리 부유하는 상황에서 성급하게 구현에 뛰어드는 것은 변경에 취약하고 다양한 협력에 참여할 수 없는 비자율적인 객체를 낳게 된다.

 

● 객체가 다른 객체에게 주어진 책임을 수행하도록 요청을 보내는 것을 메시지 전송이라고 한다. 따라서 두 객체 간의 협력은 메시지를 통해 이뤄진다.

 

● 구체적인 객체로 추상적인 역할을 대체해서 동일한 구조의 협력을 다양한 구조의 협력을 다양한 문맥에서 재사용할 수 있는 능력은 과거의 전통적인 패러다임과 구분되는 객체지향만의 힘이다.

 

4.5 객체지향 설계 기법

● 책임-주도 설계(Responsibility-Driven Design)

- 책임-주도 설계에서는 시스템의 책임을 객체의 책임으로 변환하고, 각 객체가 책임을 수행하는 중에 필요한 정보나 서비스를 제공해줄 협력자를 찾아 해당 협력자에게 책임을 할당하는 순차적인 방식으로 객체들의 협력 공동체를 구축한다. 책임-주도 설계는 개별적인 객체의 상태가 아니라 객체의 책임과 상호작용에 집중한다.

 

● 디자인 패턴(Design Pattern)

- 디자인 패턴은 책임-주도 설계의 결과를 표현한다. 패턴은 모범이되는 설계다.

 

- 특정 상황에 적용 가능한 디자인 패턴을 잘 알고 있다면 책임-주도 설계의 절차를 순차적으로 따르지 않고도 시스템 안에 구현할 객체들의 역할과 책임, 협력 관계를 빠르고 손 쉽게 포착할 수 있을 것이다.

 

● 테스트-주도 개발(Test-Driven Development)

- 테스트-주도 개발의 기본 흐름은 실패하는 테스트를 작성하고, 테스트를 통과하는 가장 간단한 코드를 작성한 후, 리팩터링을 통해 중복을 제거하는 것이다.

 

- 테스트-주도 개발은 객체가 이미 존재한다고 가정하고 객체에게 어떤 메시지를 전송할 것인지에 관해 먼저 생각하라고 충고한다. 그러나 이 같은 종류의 충고는 역할, 책임, 협력의 관점에서 객체를 바라보지 않을 경우 무의미하다.

 

- 테스트-주도 개발은 테스트를 작성하는 것이 아니라 책임을 수행할 객체 또는 클라이언트가 기대하는 객체의 역할이 메시지를 수신할 때 어떤 결과를 반환하고 그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드의 형태로 작성하는 것이다.

 

- 테스트를 작성하기 위해 객체의 메서드를 호출하고 반환값을 검증하는 것은 순간적으로 객체가 수행해야 하는 책임에 관해 생각한 것이다. 테스트에 필요한 간접 입력 값을 제공하기 위해 스텁(stub)을 추가하거나 간접 출력 값을 검증하기 위해 목 객체(mock object)를 사용하는 것은 객체와 협력해야 하는 협력자에 관해 고민한 결과를 코드로 표현한 것이다.

 

5. 책임과 메시지

의도는 "메시징"이다. 훌륭하고 성장 가능한 시스템을 만들기 위한 핵심은 모듈 내부의 속성과 행동이 어떤가보다는 모듈이 어떻게 커뮤니케이션하는가에 달려있다.
Kay (1998)

 

● 메시지는 수신자, 메시지 이름, 인자의 순서대로 나열하면 메시지 전송이 된다. 예) 모자장수.증언하라(어제,왕국)

 

● 메시지를 처리할 수 있다는 것은 객체가 해당 메시지에 해당하는 행동을 수행해야 할 책임이 있다는 것을 의미한다. 따라서 메시지의 개념은 책임의 개념과 연결된다. 송신자는 메시지 전송을 통해서만 다른 객체의 책임을 요청할 수 있고, 수신자는 오직 메시지 수신을 통해서만 자신의 책임을 수행할 수 있다. 따라서 객체가 수신할 수 있는 메시지의 모양이 객체가 수행할 책임의 모양을 결정한다.

 

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

 

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

 

● 기본적으로 다형성은 객체들 사이의 대체 가능성을 의미한다. 왕의입장에서 요리사와 앨리스는 모자 장수를 대신해서 증언할 수 있다. 이들이 대체 가능한 이유는 왕의 관점에서 동일한 메시지를 처리할 수 있기 때문이다. 비록 메시지를 처리하는 방법인 메서드는 달라지더라도 말이다.

 

● Class가 코드를 구현하기 위해 사용할 수 있는 중요한 추상화 도구인 것은 사실이지만 객체지향의 강력함은 class가 아니라 객체들이 주고받는 메시지로부터 나온다.

 

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

- 자율적인 책임은 협력을 단순하게 만든다.

- 자율적인 책임은 모자 장수의 외부와 내부를 명확하게 분리한다.

- 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다.

- 자율적인 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다.

- 객체가 수행하는 책임들이 자율적일수록 객체의 역할을 이해하기 쉬워진다.

 

6. 객체 지도

유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.
Heraculitus of Ephesus

 

● 지도는 기능에 비해 상대적으로 잘 변하지 않는 안정적인 지형정보(구조)를 기반으로 하고있다. 따라서 A에서 B로 이동한다 했을때 구체적인 위치는 사람마다 다르지만, 요구사항이 계속 변해도 지도는 모든 요구사항을 수용할 수 있다.

 

● 일반적으로 기능을 수집하고 표현하기 위한 기법을 유스케이스 모델링 이라 하고, 구조를 수집하고 표현하기 위한 기법을 도메인 모델링 이라고 한다.

 

● 소프트웨어 사용자가 자신이 관심을 갖고있는 특정한 분야의 문제를 해결하기 위해 소프트웨어를 사용한다. 이처럼 사용자가 프로그램을 사용하는 대상 분야를 도메인 이라고 한다.

 

● 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 유스케이스 라고 한다.

 

7. 부록 A

● 세상에 존재하는 객체에 개념을 적용하는 과정을 분류라고 한다.

 

● 타입은 개념과 동의어이며 속성과 행위가 유사한 객체에 공통적으로 적용되는 관념이나 아이디어이다

 

---

3. 읽은소감

● 장점

장점은 당연하게도 객체지향에 대한 나의 시각이 조금은 향상되었다는 것 이다. 사실 책한권 읽고 갑작스럽게 나의 코딩실력이나 설계 능력이 향상되리라고는 전혀 기대하지 않았다. 다만 조금이나마 코딩을 할때 멀리 볼수있는 눈을 기르기 위해 책을 읽었다. 6장에서 유스케이스와 도메인 모델이 조금 이해 안가 6장만 2번 읽은점 말고는 읽는데 큰 무리는 없었다. 책을 읽은후 객체지향 설계를 할때 메시지의 중요성을, 도메인 모델을 이용하는 방법을, 마지막에 메서드를 구성하도록 노력하는 방식등 습관잡아야할 방향을 알려주어 좋았다.

 

이책은 또한 이상한 나라의 엘리스 라는 고전의 내용을 인용하여 객체와 협력에 대한 이해를 돕는다. 이로인하여 이 책이 진가를 발휘하는것 같다.

 

책 자체는 250페이지 정도로 맘먹으면 3일정도면 다 읽을양인데, 문제는 한문장 한문장 곱씹어 다시 생각해야할 부분이 많아 시간이 오래걸린다.

 

다 읽고나니 객체지향이 무엇이다 라고 내 스스로 말할수 있는 정도는 되는것 같다. 디테일하게 설명해주신 부분까지 모두 체화하려면 진짜 오랜시간이 걸릴것이다. 이는 내가 좀더 C++을 몇년더 공부한후 향후 다시 읽어보며 좀더 음미해볼 생각이다.

 

● 단점

음 다 좋은내용이기는 한데, 그 좋은내용이 너무 중복되서 나온다. 중복 내용을 다 빼면 책이 100페이지는 더 줄어들것 같다. 물론 앞에서 한말 뒤에서 다시 말해주면 좋지만, 문제는 너무 심하게 동어반복을 하는단원이 있다. 같은 말 반복하는 책은 읽으면 읽을수록 지겨워진다는 단점이 있다.

 

이글의 모든 책의 사진이나 내용은 조영호 님께 에게 있습니다.