이상한 나라의 객체 - 객체지향의 사실과 오해

 흔히 객체지향에 대해 처음 배울 때, '객체란 실세계의 사물을 모방한 것' 이라는 표현을 자주 사용한다. 아쉽게도 이 표현은 객체지향의 기반을 이루는 개념을 간단히 표현하기에는 적합하지만, 정확하게 말하자면 틀린 표현이라고 한다. 대다수의 개발자들은 객체지향 애플리케이션이 실세계를 모방해야 한다는 설명을 전혀 납득하지 못한다.

 

 우리는 객체지향에 대해 더 자세히 이해하고자 이 책을 보거나 이 글을 찾아왔을 것이다. 우리와 같은 사람들은 이제 '객체지향은 실세계의 사물을 모방한 것'이 아닌 실제 개발에 도움이 될 수 있는 객체지향에 대한 정의를 내려봐야 할 것이다. 모든 사람들의 객체지향에 대한 정의는 같지 않을 것이다. 그렇다고 단순 시험을 위해 모두 똑같이 암기한 객체지향은 실제 개발에 큰 도음이 안될 것이다. 객체지향을 제대로 이해하고 활용하기 위해서는 자신만의 객체지향의 대한 정의가 필요하다고 생각한다. 그리고 이 책은 자신만의 '객체지향'에 도달할 수 있는 기반을 만들어 줄 것이다.

 

 

1장 - 협력하는 객체들의 공동체

 이번 장에서는 객체지향 패러다임의 핵심이 자율적인 객체들의 협력이라는 말한다. 

1. 실세계의 모방 관점에서의 객체지향

2. 협력적, 자율적

3. 클래스 보다는 객체에 집중하라

 

2장 - 이상한 나라의 객체

객체란 무엇인가? -> 상태, 행동, 식별자

 

객체가 실세계의 모방이라면, 캡슐화가 되어있지 않은 상태라고 할 수 있다.

-> 객체는 '메시지'를 받아 '스스로' 움직여야 한다. 객체라고 부를 수 있는 모든 것들이 생명을 가진 것처럼 능동적으로, 자율적으로 움직일 수 있어야 한다. 물을 마시면 내가 물을 마시기 때문에 물이 사라지는것이 아니라, 물이 내가 물을 마시는 것을 알고 스스로 자신의 양을 줄여야지 캡슐화가 되어있다고 볼 수 있다. 이것은 실세계에서는 불가능한 현상이다.

 

행동이 상태를 결정한다(RDD). 이를 지키지 않고 상태를 먼저 설계하면 캡슐화를 망친다.

 

3장 - 타입과 추상화

추상화 -> 필요한 것만 남기고 필요하지 않은 것을 제거.

예: 지하철 노선도에서 '경로'만 남기고 '실제 지형 정보'는 제거함으로써 내가 가고 싶은 경로에만 집중할 수 있게 추상화

행동의 파악 -> 시각화하면 더육 효과적

 

 

 이번 범위에서 가장 인상깊었던 포인트들을 뽑아보자면 다음과 같다.

- 클래스보다는 객체에 집중 하라

- 객체란 현실의 사물의 은유적

- 현실 속에서는 수동적인 존재가 소프트웨어 객체로 구현될 때는 능동적으로 변한다.(의인화)

- 행동이 상태를 결정한다

 

 객체지향 프로그래밍은 '객체들의 상호작용'을 중심적으로 생각하며 프로그램을 설계해나가야 한다. '클래스'에 너무 얽메이지 말고, 객체들의 '행동'을 우선적으로 프로그램을 설계해보자. 객체지향프로그래밍을 잘하는 사람들의 코드를 보면 기능에 필요한 요소들을 잘 쪼개서 클래스와 인터페이스를 설계하던데, 내 코드를 보면 너무 거대한 뭉텅이들만 가득하더라. 이전의 나의 설계방식을 되돌아보자면, 먼저 기능 자체에서 필요한 상태를 정해놓고, 그 상태를 기반으로 행동을 정의해왔던것 같다. 한 개의 거대한 태스크에 대해 상태를 만들고, 객체들의 상호작용을 생각하지 않으니 하나의 거대한 클래스가 자꾸 튀어나온 것 같다. 앞으로는 객체 자체에 집중하여 프로그램을 설계해보자.