[객체지향의 사실과 오해] 인사이트 정리 겸 회고

객체지향의 사실과 오해를 읽고 인사이트 정리 겸 회고

---

읽기 시작한 지는 꽤 되었지만, 이런저런 이유로 미루고 미루다 회사에서 객체지향 프레임워크도 다루기 시작했고 읽고 싶었던 책을 읽기 위해 밀린 책을 쳐낼 겸 독파했다..

 

밀렸던 블로그도 이를 계기로 다시 시작할 예정

이제는 보여주기식이 아닌 진짜 일기장처럼 끄적임으로 작성해야겠다고 다짐ㅋㅅㅋ

 

초중반 부분은 객체지향의 패러다임과 객체지향 사고의 관점을 이해시키기 위해 카페의 생리(손님 <-> 점원 <-> 바리스타)와, 이상한 나라의 앨리스에서 재판을 받는 부분(왕 <-> 하얀 토끼 <-> 모자장수)을 비유 삼아 이야기를 풀어나간다.

개인적으로 객체지향은 학교 수업만 듣고 자꾸 클래스에 한정 지어 생각하고 개념적으로 붕 떠있는 부분들이 있었는데, 이러한 비유들로 접근하니 좀 더 구체적으로 와닿아 좋았다.

 

결론적으로 이 책의 핵심은 부제에 스포가 되어있듯이 객체지향 프로그래밍을 하려면

1. 역할
2. 책임
3. 협력

위 3가지 관점에서 고민하고 설계를 해야 한다는 것이다.

 

카페로 예시를 들면 역할에 따라 손님, 점원, 바리스타 이 3가지의 객체가 존재하고,

손님은 주문을 하는 역할, 점원은 주문을 받는 역할, 바리스타는 주문받은 커피를 만드는 역할이다.

또한, 손님은 커피를 주문하고 기다렸다가 점원에게 주문한 커피를 받아 돌아가야 할 책임, 점원은 손님의 주문을 받고 바리스타에게 주문받은 커피를 알리며 바리스타가 만든 커피를 손님에게 전달해야 할 책임, 바리스타는 점원으로부터 부탁받은 커피를 만들어야 할 책임이 있다.

그리고 이 역할과 책임에 따라 3가지 객체(손님, 점원, 바리스타)가 각기 협력을 함으로써 카페가 원활하게 돌아가는 것이다.

 

앞으로 객체지향 프레임워크를 사용하거나 코드를 칠 때 위 3가지 관점을 녹여 내려 노력해야겠다..

 

중후반 이후에는 좀 더 추상적인 개발관점에 대해 많은 이야기가 서술되어 있었고, 현재 내 지식수준과 1 회독 만으로는 받아들일 수 있는 인사이트의 한계가 있었지만 정리를 해본다.

 

• 인터페이스나 메서드(함수) 설계 시 메시지(파라미터)에 초점을 두어 설계하자
  메시지가 객체의 공용 인터페이스의 모양을 암시 => 책임-주도 설계 방식의 What/Who 사이클과 관련된다.
  하다못해 네이밍이나 기능을 함수로 찢을 때에도 나는 로직이나 리턴할 값에 초점을 두었었는데 메시지를 먼저 생각하려는 습관을 들여야겠다고 생각했다.

 

• 객체지향적인 사고방식을 이해하고 잘 녹이려면 3가지 원칙을 떠올리자
  1. 추상적인 인터페이스를 설계하자
  2. 인터페이스 최소화 하자
  3. 인터페이스와 구현 간에 차이를 두고 이를 인식하자

 

• 객체지향의 강력함을 누리기 위한 출발점은 책임을 자율적으로 만드는 것이다
  예를 들어 판사와 목격자가 있을 때 판사가 목격자에게 지나치게 상세한 수준의 메시지(목격했던 장면을 떠올려주세요, 떠오르는 기억을 시간순으로 재구성해서 알려주세요, 말로 간결하게 표현해 주세요 등)를 보내는 것은 객체의 자율성을 저해하게 된다.
  따라서, 추상화된 메시지(증언해 주세요.)를 사용하는 것이 수신자의 자율성이 보장되므로 더 좋은 인터페이스 설계이다.

 

• 미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용하는 것이다
  헤라클레이토스의 명언을 인용한다. (유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.)
  훌륭한 설계자는 어떤 변경이 발생할지 예측하는 것이 아니라, 어떻게 변경이 발생할지 알 수없으며 언젠가 변경이 발생한다는 사실을 겸허히 받아들이는 사람이다.
  따라서 좋은 설계 = 나중에 일어나는 변경을 할 수 있게 여지를 남겨놓는 설계이다.
  설계의 목적은 나중에 일어날 변경으로 인한 재설계를 허용하는 것이고, 일차 목표는 변경에 대한 소요 비용을 낮추는 것이다.

 

• 모델링 관점 (유스케이스, 도메인, 멘탈)
  길을 잃었을 때 목적지를 찾아가는 방법에 비유를 한다.
  지나가는 사람에게 길을 물어 방법(기능적, 유스케이스 모델링)과 지도를 보는 방법(구조적, 도메인 모델링)이 있다.
  하지만 유스케이스 모델링과 도메인 모델링 말고 멘탈 모델링 또한 중요하다.
  멘탈 모델이란 이해관계자들이 상호작용을 하는 사물들에 갖는 일종의 모형이다.
  예를 들어, 은행업무 종사자는 은행 도메인을 고객과 계좌 사이의 돈의 흐름이라고 생각할 것이고,
  중고 자동차 판매상은 자동차 도메인을 구매되는 자동차와 판매되는 자동차의 교환 흐름이라고 생각할 것이다.
  이처럼 실제 세계의 모델링을 할 때에는 도메인 모델링뿐 아니라 이해관계자들의 멘탈 모델링 또한 부합시키는 것이 중요하다.