객체 지향의 사실과 오해 - 이건 띵작이야
객체 지향 프로그래밍(Object Oriented Programming)은 여전히 트렌드이고, 좋다는 걸 다들 안다. 그런데 OOP가 무엇인 지, 왜 좋은 지를 설명하는 건 생각보다 쉽지 않다.
이 책을 읽으면 객체 지향의 핵심이 무엇이고 이걸 쓰면 왜 좋은지 어렴풋이 알 수 있다. 저자는 서문에서 이 책을 '어쩌다 만들어진 책'으로 소개한다. 객체 지향에 대한 책을 쓰다가, 독자가 이해하기 어려울 용어를 정리하는 과정에서 탄생한 책이니까!
그래서 쉽다!!! 이 내용의 밀도에 비해 정말 술술 익힌다... 책 속에 등장하는 은유는 참 찰지다... 객체 지향 프로그래밍을 처음 접하는 사람에게 이 책만큼 권할 저서가 다시 나올까 싶을 정도다.
인상 깊은 구절을 내 나름의 언어로 옮기자면
컴퓨터의 모든 동작은 결국 '전자의 움직임'으로 치환할 수 있다. 그러므로 프로세스, 스레드는 전부 믿음이고 신앙이다. 스레드는 없고 어떤 전자의 움직임만 있다. Integer도 마찬가지이고 Byte도 마찬가지다. 전자의 움직임을 추상화해서 개념으로 만든 걸 타입이라고 한다. 이 타입의 인스턴스를 객체라 한다.
그럼 객체 지향 프로그래밍의 객체도? 당연히 객체 타입의 인스턴스다. 그러면 그 객체 타입을 어떻게 정의하느냐!~ CLASS가 아니다!!! CLASS === 객체가 아니다!! 이 때 책의 부제에 떡~하니 있는 '역할 책임 협력'이 등장한다.
흔히 '객체는 현실 세계의 반영이다.' 라고 하지만 이 말은 반은 맞고 반은 틀렸다. 현실 세계를 빗대어서 객체를 설계하면 이해가 쉽다는 장점이 있다. 하지만 현실 세계에서 일어나지 않는 일이 객체 세계에서 일어난다. 예를 들어서 현실에서는 '사람이 물을 마셨다.'라고 하면 컵과 물은 가만히 있고 사람만 능동적으로 행동한다(물을 마신다). 하지만 객체의 세계에서는 사람과 컵이 모두 능동적으로 참여할 수 있다. 그렇기 때문에 객체가 현실의 반영이라는 말은 반은 맞고 반은 틀렸다.
그러므로 객체지향 설계는 다음과 같이 이루어져야 한다. 예를 들어 카페 주문 프로그램을 만든다면
| 1. 어떤 결과를 낼 것인가? | 1. 커피숍 프로그램을 만들려고 한다. |
| 2. 그것에 필요한 건 어떤 행동인가 | 손님이 메뉴판을 읽고 웨이터에게 주문한다. |
| 웨이터는 주문을 받고 바리스타에게 주문한다. | |
| 바리스타는 주문을 받고 커피를 만든 후 웨이터에게 건네준다. | |
| 웨이터는 바리스타에게서 커피를 받고 손님에게 건넨다. | |
| 3. 그 행동은 누구의, 어떤 협력을 통해 이루어질 것인가? | 손님 - 웨이터 : 주문, 커피 주고받기, |
| 웨이터 - 바리스타 : 주문 주고받기, 커피 주고받기 | |
| 4. 객체에게 그 행동에 대한 책임과 역할을 부여한다. | 손님 - 메뉴판 읽기, 주문하기, 커피 받기 |
| 웨이터 - 주문하기, 커피 받기, 커피 건네기 | |
| 바리스타 - 주문받기, 커피 만들기, 커피 건네기 |
이런 식으로 만들 수 있다. 보면 알겠지만 각 객체는 능동적으로 협력에 참여한다.
예를 들어서
손님은 바리스타가 커피를 어떻게 내리는 지 알 수 없다. 커피를 내리는 방법은 바리스타의 고유한 영역이다.
어느 날 바리스타가 바뀌어도 손님은 상관하지 않는다. 커피만 받을 수 있으면 된다.
이러한 캡슐화는 선언과 구현을 엄밀히 구분하고 객체의 내부는 오로지 객체 스스로만 제어함으로써 에러 가능성을 줄이고 유지 보수를 쉽게 하며 프로그램의 전체적인 안정성을 높인다. 수정도 간단하다!
이외에도 책은 흥미로운 은유와 내용으로 가득차있다.
이 책을 무척 추천한다!!!