객체지향의 사실과 오해

책을 읽은 이유

토이 프로젝트를 하면서 고질적인 문제가 있었는데
어느 정도 구현이 끝나면 의미 없는 리팩토링 관련 커밋들만 계속 올라가는 것이었다.

어제는 이게 명쾌한 해답 같았지만, 다음 날 다시 보니 여전히 문제가 있는 코드였고,

이러다 보니 리팩토링만 하다 프로젝트에 흥미를 잃어 레포를 지우고 다른 프로젝트를 시작하는 일들이 빈번히 발생했다.

 

이렇듯 설계에서 계속 문제가 발생했기 때문에, 객체 설계 관련 책을 보면 어떨까 싶었다.
그래서 본 책이 객체지향의 사실과 오해란 책이었다.

 

책을 읽는 과정에서 어느 부분에서 설계가 꼬이게 됐는지 유추할 수 있었다.
모든 부분이 중요했지만, 그 중 나한테 있어 필요한 부분들에 대해 우선적으로 정리를 했다.

역할, 책임, 협력

이 책에서 가장 강조하는 3가지 단어다.
객체들은 자신의 "역할"에 부여받은 "책임"을 가지고 협력에 참여한다.

역할의 특징

• 관련성 높은 책임들의 집합
• 여러 사람이 동일한 역할 수행 가능 즉, 대체 가능성이 있다.
• 부여된 책임을 자유롭게 수행할 수 있다.
• 한 사람과 여러 역할을 수행할 수 있다.

책임의 특징

• 한 역할이 요청을 받고 수행할 수 있는 행동들
• 구체적이기보단 추상적이어야 한다. (너무 구체적이면 자유롭게 처리 불가)
• 책임은 2가지로 분류된다.
  • 하는 것(doing)
    • 객체를 생성하거나 계산
    • 다른 객체의 행동을 시작
    • 다른 객체의 활동을 제어하고 조절
  • 아는 것(knowing)
    • 요청 수행에 관련된 객체를 아는 것

협력의 특징

• 협력의 주체는 객체
• 협력 안에서 객체들은 협력적이어야 한다. 즉, 모든 기능이 집약된 객체는 지양한다.
• 협력관계 안에서 객체들은 자율적으로 행동할 수 있어야 한다.

how가 아닌 what

객체 간 협력 과정에선 다른 객체가 무엇을 할 수 있는지는 알지만 어떻게 하는지는 알지 못해야 한다.

 

만약, 어떻게 하는지를 안다면 객체의 행동을 구체적으로 지정할 수 있게 되고 해당 객체는 자신의 책임을 자유롭게 수행할 수 없게 된다.

이는 곧, 객체 간 결합도의 증가로 이어지기 때문에, 주어진 책임을 추상화해 세부 행동을 알 수 없게 해야 한다.

 

예를 들자면 손님은 바리스타에게 커피 제조를 요청한다.

이 과정에서 바리스타에게 원두를 어떻게 갈고 물의 양을 어떻게 하는지를 세세하게 정해서 요청하면
바리스타는 주어진 책임을 자유롭게 수행하지 못해 강하게 결합된다.

이를 해결하기 위해, 손님은 바리스타의 커피 제조 방식에 관여하지 않고, 요청만 한다.

이렇게 구체적인 메서드를 숨기고, 커피 제조란 추상적인 메서드만 보여준다.

손님은 바리스타의 내부 상태 변화를 알지 못하게 되고, 이는 캡슐화와 연관이 된다.

추상화가 아닌 은유로 객체를 묘사

현실 세계의 사물을 추상화하는 게 묘사하는 것이다.
이 과정에서 현실 속 객체의 이름을 이용해 표현적 차이를 줄인다.

 

이 책에서는 이상한 나라의 앨리스에서 나오는 트럼프 카드들을 예시로 들었다.

이상한 나라의 트럼프 병사들은 우리가 아는 트럼프와 유사하지만, 현실과는 다르게 움직이고 말할 수 있다.

 

실제 코드를 보면 어떤 객체들은 우리가 아는 현실의 사물과는 다른 특성을 가지고 있던 경우를 자주 봤는데
그것이 여기에 대한 경우란 생각이 들었다.

추상화를 통한 일반화

이전 장에선 추상화가 아니라 하고, 다음 장에선 추상화에 대한 얘기가 나와서 잠깐 헷갈렸었다.

정리하면 추상화를 통해 객체를 일반화하고, 이 일반화된 타입을 은유를 통해 현실 객체의 사물로 묘사하는 것이었다.

 

추상화는 다음과 같은 과정을 거쳐 객체를 일반화한다.

• 공통점은 취하고, 차이점을 버려서 일반화를 시킨다.
• 중요한 점을 강조하기 위해 세부 사항은 제거한다.

정리하면 추상화를 통해 인터페이스나 추상 클래스를 만들고,
은유를 통해 인터페이스나 추상 클래스를 구체화한다.

책임 주도 설계

이 책에서 주로 강조하는 부분은 책임이다.
따라서, 적절한 책임을 객체에 할당하는 것이 객체지향 설계의 핵심이라고 한다.

 

책임을 분할하는 과정에서 스스로 처리할 수 없는 정보나 기능은 관련 책임을 가지는 객체에게 요청을 한다.
이 과정에서 하나의 협력이 만들어진다.

 

만약, 책임을 수행할 객체가 여러 종류라면 추상화된 객체와 협력 관계를 가지게 한다.

테스트 주도 개발

책임과 협력 관점에서 코드를 짤 수 있게 해주는 개발 방법.

단순 테스트가 아니라, 객체가 메시지를 수신할 때, 어떤 결과를 반환하고,
그 과정에서 어떤 객체와 협력할 것인지에 대한 기대를 코드의 형태로 작성한다.

객체지향 설계의 능력을 잘 보여줄 수 있는 개발 방법.

메시지

이 책에서 강조하는 요소 중 하나.

 

책임을 수행하는 과정에서 다른 객체와의 협력이 필요한 경우
관련 객체에게 요청을 하게 되는데 이것을 메시지라고 한다.

따라서 메시지는 객체들이 협력하기 위해 사용할 수 있는 유일한 소통 수단이다.

 

객체가 메시지를 수신할 수 있다는 것은 객체가 메시지에 해당하는 책임을 수행할 수 있거나
해당 책임을 수행할 객체를 알고 있다는 것이다.

 

객체는 메시지를 자신만의 방식으로 처리하면서 자율적인 협력 관계를 가질 수 있다.

what/who 사이클

객체 사이의 협력 관계를 설계하는 방법

어떤 행위(what)를 수행할 것인지 결정 -> 누가(who) 그 행위를 수행할 것인지 결정
여기서 어떤 행위란 "메시지"를 뜻한다.

 

즉, 필요한 메시지를 결정한 후에 메시지를 수신할 객체를 선택한다.

위에서 설명한 책임 주도 설계는 이 사이클을 통해 메시지와 객체를 결정한다.

마치면서

이 책을 읽고 나서 깨달은 부분은 많았지만, 이것들을 글로 정리하는 것은 매우 어려웠고, 분량도 너무 많았다.
차라리 챕터별로 정리를 하는 게 좋지 않았나란 생각도 많이 들었다.

 

지금은 책의 내용을 알고 있겠지만, 시간이 지나면 다시 잊게 될 것이란 생각이 들었기에
나한테 있어 필요한 부분들에 대해 우선적으로 정리를 했다.

 

언젠가 좀 더 큰 규모의 개발을 하게 되면 다시 이 책을 보게 될 것이고 그때가 되면 좀 더 잘 정리할 수 있을 것이다.