CH02 이상한 나라의 객체

왜 상태가 필요한가

앞서 객체는 상태와 행동의 묶음 단위라고 했는데, 상태가 왜 필요한지에 대한 내용이 있었다. 솔직히 처음에는 좀 억지같았는데 계속 생각해보니 객체에 상태가 있게 된 것이 직관적으로 저자의 논리와 일치한다는 생각이 들었다.

저자는 객체에 상태가 있게된 이유(상태 라는 개념을 고안한 목적)가 행동의 결과를 알기 위해서 이전의 모든 행동 이력을 추적할 수 없으니 상태라는 값을 뒀다고 한다. 사실 실제 세계에는 상태라는 개념이 항상 존재하는데, 그저 생각 없이 실제 세계에 존재하기 때문에 객체 세계에도 가져온 것 같지만 상태의 근본적인 효용은 결국 저자의 설명이 맞다고 본다.

객체의 협력을 잘 이루기 위해서 객체의 행동이 적절한 결과를 만들어야하고, 이 적절한 결과를 보다 용이하게 만들어 내기 위해서 상태라는 개념을 두고 행동의 이력을 결과값으로 보관하는 것이다.

상태와 프로퍼티

객체의 상태는 단순한 값과 객체 두 가지로 구성될 수 있다. 책에서는 단순한 값을 '속성' 이라고 표현하는데 이 표현을 굳이 이해하고 인지하고 있을 필요는 전혀 없다.

그리고 다시 강조하고 있지만 객체의 상태는 스스로의 행동에 의해서만 상태가 변경되는 것을 보장함으로써 객체의 자율성을 유지할 수 있다.

행동

책에서 정의하는 객체의 행동은 아래와 같다.

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

개인적으로 이 말이 다 맞는 표현 같지는 않다. 행동은 외부에 가시적이어야 한다는 것이 애매한 표현이다. 가시적인 행동이 있고 숨겨야할 행동이 있는데 마치 모든 행동이 다 가시적이어야하는 것처럼 묘사되고 있다.

행동의 결과로 자신의 상태를 변경하거나 다른 객체에게 메시지를 전달한다는 부분만 인지하자.

상태 캡슐화

이 부분의 설명이 좀 재미있었다. 전지적 관찰자 시점(개발자의 시점)이 아니라 객체의 시점에서 다른 객체를 바라보는 것이었다.

객체는 자율적이어야 하며, 자율적인 객체는 상태를 외부에 공개하지 않는다. 행동에 대한 과정도 간섭받지 않는다. 이러한 맥락에서 특정 객체에 요청을 보내는 객체는 요청을 수행하는 객체가 이를 잘 수행할 것이라고 믿고 요청을 할 뿐이다.

이것이 곧 캡슐화이며 캡슐화가 잘 이뤄질 수록 객체의 자율성을 높힐 수 있고 결국 협력을 단순하고 유연하게 만들 수 있다. 결과적으로 유연한 어플리케이션 설계가 된다.

행동이 상태를 결정한다

많은 분량으로 강조되는 부분이다. 저자는 흔히 초보들이 객체를 설계할 때 해당 객체가 어떤 상태들을 지닐지를 먼저 고민한다고 한다. 앞서 객체는 상태와 행동의 묶음 단위라고 했는데, 여기서 객체를 설계할 때 해당 객체가 어떤 상태들을 가질지에 대해서 행동보다 먼저 고민한다는 것이다.

이러한 접근은 나쁜 설계를 불러올 가능성이 크다고 강조한다. 책에서 세가지 이유를 들고 있는데 개인적으로 각 이유에 대한 설명이 구체적이지 않아서 와닿진 않는다. 다만, 나도 경험해보았기에 저자의 생각에 대해서는 동의를 한다.

핵심은 객체 설계는 객체간 협력의 관점에서 이뤄져야하고, 객체간 협력은 결국 객체의 행동에 의해서 발생되기 때문에 행동을 먼저 생각하고 필요한 상태를 생각해야하는데 이것이 반대가 되면 불필요한 상태가 늘어나거나 협력에 더 적합한 객체가 설계되지 못할 수 있다.

객체지향생활체조 원칙 중 '3개 이상의 인스턴스 변수를 가진 클래스를 쓰지 않는다.'는 원칙이 있다. 나의 경험(NEXTSTEP 에서 클린코드 강의를 들을때 받았던 피드백) 상 이 원칙을 위배해서 피드백을 받았었는데, 무지성으로 그냥 상태를 먼저 생각하고 설계를 했더니 실제로 불필요한 상태 값이 생겼고 최대한 줄이고자 노력해보니 실제로 줄어들게 되었다.

예를 들어 두 세가지의 상태가 하나의 객체로 다시 묶일 수 있다던가, 단지 해당 객체가 로직 처리를 위해서 임시로 갖게되는 값들이 생기게 되었다. 하지만 public 메소드(행동)을 위주로 생각하게 되니 정말 필요한 값만 프로퍼티로 가지게 되었다.

결론은 객체를 설계할 때는 객체의 상태보다 객체의 행동을 먼저 생각하고, 다른 객체와의 협력이라는 맥락에서 해당 객체가 어떤 상태를 가져야할지를 고민해야한다는 것이다.

행동을 먼저 생각하고, 행동을 위해서 반드시 필요한 정보가 무엇인지 생각해보고 이 과정에서 필요한 상태가 무엇인가를 고민해보자.

행동이 상태를 결정한다.

의인화

CH01 에서 이미 한 번 지적한 사항인데 객체 지향은 실제 세계의 모방이 아니다. 이렇게 말할 수 있는 것은 실제 세계와 객체 지향의 세계가 큰 차이를 가지고 있어서이다. 여기서 큰 차이는 현실 속에서는 수동적인 존재가 객체 세계에서는 능동적으로 변한다는 것이다. 저자는 이 핵심이 '의인화'라고 말하고 있다.

결국 인간이라는 에이전트 없이 현실의 전화는 서로에게 전화를 걸지 않으며 색은 스스로 칠하지 않는다. 일상적인 체계에서는 어떤 사건이 일어나기 위해 반드시 인간 에이전트가 필요한 반면 객체들은 그들 자신의 체계 안에서 능동적이고 자율적인 에이전트다.

예를 들어서 '장바구니'를 '일급 컬렉션'으로 구현해서 해당 객체가 알아서 총 얼마인지 계산하게끔 만들 수 있다. 하지만 현실 세계에서는 장바구니는 단지 살 물건들이 담긴 공간 내지는 품목일 뿐 자율적으로 뭔가를 할 수 있는 존재가 아니다.

또다른 예를 들면 '물컵' 을 구현했다고 했을 때 현실에서는 사람이라는 존재가 물컵의 물을 마셔줘야 물컵이 가지고 있는 물의 양이 줄어들지만, 객체 지향의 세계에서는 물컵이 알아서 물의 양을 줄일 수 있다. 이것이 책에서 말하는 의인화이다.

은유

저자는 계속해서 객체 지향은 현실 세계의 모방이 아니라는 것을 강조하는데, 그렇다고 해서 실제 세계와의 관련성을 모두 부정하는 것은 아니다. 다만 모방의 수준이 아니라 다른 관점에서 유사성을 가지고 있다는 것인데 저자가 객체 지향과 실제 세계의 관계를 정확하게 표현할 수 있는 개념으로 '은유'를 말한다.

실제 세계와 동일하거나 유사한 것을 객체 세계의 창조에 차용 할수록 '의미적 차이'가 줄어들기 때문에 차용을 많이 해줄 수록 소프트웨어의 구조를 더 쉽게 파악할 수 있다고 한다.

그래서 객체 지향은 현실 세계와 무슨 관계인가

저자가 객체 지향은 현실 세계의 모방이 결코 아니라고 하면서도 관계성을 부정하지 않으니 종합적인 판단은 독자들이 해야한다. 물론 저자가 어느정도 정리된 문구로 이를 표현하고 있지만 이 관계에 대한 종합적인 의견을 따로 소주제나 단락을 할애해서 정리해서 말하고 있지는 않다.

결론적으로 객체 지향은 현실 세계와 완전히 다른 세계이다. 근본적으로 완전히 다른 세계이다. 핵심적인 차이는 현실 세계에서 불가능한 것들이 객체 지향의 세계에서는 가능하고 또 필요하기 때문이다. 더 구체적으로 말하자면 객체 지향의 세계에서는 정교하고 구체적인 협력을 위해서 현실 세계에는 없는 완전히 새로운 논리적이고 추상적인 개념을 객체로 만들어 사용하고 있으며, 각 객체는 '의인화'를 적극적으로 활용하고 있다.

이러한 맥락에서 현실 세계와는 별개로 객체 지향은 완전히 새로운 세계로 창조되는 세계이지만 '의미적 차이'가 적을 수록 소프트웨어의 복잡성이 낮아질 수 있으므로 객체 지향의 세계에서는 현실 세계의 여러가지 개념을 적극적으로 차용하는 것이 좋다.