객체 지향의 사실과 오해 - 1. 협력하는 객체들의 공동체

https://book.naver.com/bookdb/book_detail.nhn?bid=9145968 

객체지향의 사실과 오해

누구나 한 번 이상 들어봤거나 대충의 개념은 알고 있지만 상세히 설명해보라 하면 할 말을 잃게 만드는 객체 지향에 대해 알려주는 책입니다.

컴퓨터과학이 외국에서 온 학문이다 보니 명저라는 책들도 대부분 영어로 적혀 있는 경우가 많습니다. 인터넷 자료들도 주로 영어 문서이고 번역판으로는 이해가 잘 되지 않을 때도 종종 있지요. 이런 현실 속에서 개발자들이 꼭 읽어야 할 책으로 자주 입에 오르내리는 이 책이 한국 국적이라는 것이 반갑습니다.

 

객체지향이란 무엇인가?

 

객체는 외부와 구별되는 모든 사물을 말합니다. 거리의 행인들과 자동차, 신호등과 도로 같은 것들은 모두 객체입니다.  눈에 보이지는 않지만 인간이 명백히 구분할 수 있는 '신호관리시스템' 이라든가 사람과 차들이 따라야 할 '교통법규' 같은 추상적인 개념도 객체라고 할 수 있습니다. 이런 객체들은 모두 하나의 시스템 안에서 자신의 역할과 책임을 수행하기 위해 존재합니다.

거리의 사람들은 그냥 지나가는 행인, 교통경찰, 노상강도 등 다양한 역할을 가지고 있습니다.

같은 역할을 맡은 사람은 다수일 수 있습니다. 역할을 수행하는 객체는 대체 가능하기 때문입니다. 지나가는 차들은 퇴근길에 만난 경찰이 출근길에 봤던 경찰과 같은 사람인지 궁금해하지 않습니다. 반대로, 한 사람이 여러 가지 역할을 수행할 수도 있습니다. 낮에는 경찰, 밤에는 도둑

그리고 역할에는 책임이 따르게 됩니다. 교통경찰은 근엄함을 유지하면서 교통정리를 하고, 도로의 질서를 유지해야 합니다. 행인이나 자동차들은 교통법규를 준수해서 목적지로 계속 이동할 책임을 집니다.

이렇게 객체들을 배치하다 보니 그럴싸한 모양이 갖추어졌습니다. 그럼 이제 시작 버튼을 누르기만 하면 이 작은 사회가 제 구실을 할 수 있을까요?

가장 중요한 것이 빠졌기 때문에 지나가는 차들은 교통경찰을 보지 못하고 치어버리거나 서로 추돌을 하게 될 것이고 행인들은 인도와 도로를 구분하지 못하고 온 사방을 배회하며 신호등은 사이킥 조명처럼 꺼졌다 켜졌다를 반복할 것입니다. 이 사회에 부족한 것은 바로 협력입니다.

자동차 객체는 혼잡한 교차로를 통과하기 위해 교통경찰에게 요청을 보냅니다. 그러면 교통경찰은 다른 쪽 도로의 차량들이 지나간 것을 확인하고 지나가라는 응답을 보내주게 됩니다.

행인들은 교통법규 객체에게 지금 내가 가는 이 길이 사람이 가도 되는 길인지 알려달라 요청을 하고 교통법규 객체는 그곳은 도로이니 가지 말라는 응답을 보내줍니다.

이러한 요청과 응답은 메시지라는 유일한 의사소통 수단에 의해 이루어지게 됩니다.

이렇게 수많은 역할과 책임을 가진 객체들이 상호 협력하여 시스템을 굴러가게 만드는 것 그것이 바로 객체지향입니다.

 

객체가 갖추어야할 덕목과 특성

 

객체들은 충분히 협력적이되, 동시에 자율적이어야 합니다.

경찰은 차량들의 요청에 모두 응답을 해주어야 합니다. 하지만 경찰이 어떤 기준으로 차량들을 통과시키는지는 오로지 경찰이 결정할 문제입니다. 누군가 급하다고 해서 나를 먼저 보내달라 요청할 수는 없습니다.

객체는 식별자와 상태, 그리고 행동으로 구성됩니다.

자동차 객체는 저마다 차량 번호판을 가지고 있습니다. 차종이 같고 같은 속력으로 달리고 있다고 해서 내가 탄 차량과 옆에 있는 차량이 같다고 할 수는 없습니다. 이때 번호판이 식별자이며, 다른 차량과 동일성(identity) 비교를 하게 됩니다.

반면 단순한 값은 상태에 의해서 동등성(equality)이 결정됩니다. 예를 들어 오늘 날짜는 11월 15일입니다. 11월 15일이라는 상태를 가지고 있는 이상, 모두 똑같은 '오늘'입니다.

객체는 각자 상태를 가지고 있습니다. 자동차는 시동이 켜지거나 꺼질 수 있고, 정지하거나 주행 중일 수 있으며 주행 중일 때는 속도를 가집니다. 그리고 이러한 상태는 계속 변화하게 됩니다.

상태를 변하게 만드는 것은 객체의 행동입니다. 하지만 행동은 현재의 상태에 의해서 유발 또는 억제될 수 있습니다. 자동차의 속도는 가속 페달을 밟음() 으로써 증가하지만 속도가 제한속도를 넘어설 경우 브레이크() 로 속도를 낮추게 됩니다.

객체의 상태를 외부에서 직접 변경할 수는 없습니다. 외부에서는 제한 속도와 주행 가부를 알려주며 감속 또는 정지요청을 할 뿐, 현재의 속도를 봐가며 적절히 가속, 감속을 하는 것은 객체가 스스로 할 일입니다. 우리는 이것을 캡슐화(encapsulation) 라고 부릅니다.

저 같은 초보들은 순서대로 우선 값을 저장할 변수를 선언하고 그 변수들을 조작할 메서드를 선언하곤 합니다. 하지만 객체 지향의 세계에서는 행동이 상태를 결정합니다. 우리가 먼저 생각해야 할 것은 자동차가 할 수 있는 행동(시동 켜고 끄기, 속도 조절, 깜빡이 점등 등) 이고 그런 행동을 나타내는 수단으로 속도나 전원 방향지시등과 같은 상태를 결정하게 되는 것입니다. 이렇게 하지 않으면 캡슐화와 객체 간의 협력이 저해되고 재사용이 어려워지게 됩니다.

즉, 객체에게 주어진 책임이 전체 설계를 주도해야 한다는 것입니다. (RDD)

 

흔히 하는 오해

 

저자는 클래스는 도구일 뿐, 정작 중요한 것은 객체임을 잊지 말라 당부합니다. 클래스는 객체의 설계도라고 할 수 있습니다. 프로그래머 입장에서는 객체를 만든다는 것은 곧 클래스를 작성하는 것이니 눈앞에 보이는 클래스에 집중하기 쉽습니다. 하지만 이러한 관점은 프로그램의 유연성과 확장성을 해친다고 합니다.

언뜻 와닿지 않을 수 있는데 저는 이렇게 이해했습니다.

교통경찰과 자동차라는 객체들의 상호작용을 온전히 이해하고 '경찰이 수신호를 전달하기 위해서는 어떤 메서드가 필요할까?' '자동차가 요청을 한답시고 클락션을 울리면 안 되겠지?' 라는 식으로 사고의 흐름이 이루어지는 것이 바람직한 것이지,

단순히 Police 클래스, Car 클래스를 만들어서 어떤 어떤 타입의 필드와 어떤 어떤 메서드를 만들어야지 라는 것에 집착해 사고를 클래스라는 틀 안에 가두지 말라는 이야기 같습니다.

또, '객체는 현실세계를 추상화, 모델링한 것이다' 라는 명제는 엄밀히 말하면 틀렸다고 합니다. 이해를 돕기 위해 많은 경우에 객체 지향을 이런 식으로 설명하지만 현실과 소프트웨어의 객체는 엄연히 다른 것이고 이는 은유와 의인화에 더욱 가깝다는 것이죠.