객체지향의 사실과 오해 1장~2장

이 책은 혼자 읽은 책은 아니고 저번 주부터 정글에서 같이 공부했던 친구들 몇 명과 북 스터디에서 진행하기로 한 책이다.

객체지향적으로 코드를 짜는 방법론이나 이런 게 구체적으로 나와있는 책이 아니라 제목에 있는 것처럼 잘못된 오개념('프로그래머의 뇌'란 책에서 말한 그런 오개념)? 들 그리고 편견들에 대해 다시 잡으면서 올바르게 객체지향 관점으로 사고할 수 있게 도움을 줄 수 있는 책이 될 거 같다.

이번 주는 1장 ~ 2장 을 읽었는데  단순한 요약보다는 내가 읽으면서 흥미롭게 느끼거나 기억에 남았던 점들을 정리하려 한다. 

우선 본격적으로 1장에 들어가기전에 저자는 보통 우리가 객체 지향하면 클래스부터 떠올리고 그거에 관련해서만 생각하고 이야기하는 점들을 경계한다. 2장 마지막을 읽게 되면 한번 더 이런 오해해 대해서 이야기를 해준다. 1장은 객체지향이란 무엇인가?라는 물음에 대해 이야기를 한다. 본질에 대해서 정리를 하고 그 본질을 이루는 개념들을 설명해준다.

간단히 정리하면 역할, 책임, 협력 3가지로 볼 수 있다. 각 객체들은 역할이 있고 그 역할은 책임이 있기 때문에 그 책임을 다하기 위해 행동해야 한다. 이러한 역할과 책임은 협력을 통해 이뤄 질 수 있다. 그리고 이러한 본질에 중심에는 이름처럼 객체가 있다.

협력을 위한 객체는 2가지 덕목이 있는데, 첫째는 협력적이여야고 둘째는 자율적이어야 한다고 한다. 협력적이라는 건 다른 객체들과 외부에서 요청을 보내고 응답을 보내는 게 적절히 잘 이뤄져야 하는 거 같다. 간단한 예를 들면 하나의 객체가 너무 복잡한 형태가 된다면 내부적인 복잡도에 의해 자멸한다고 말한다. 이건 리팩터링 책을 읽으면서 원칙 중에도 있던 거 같은데 한 객체가 너무 복잡한 건 진짜 건강하지 않은 거 같다. 다음으로 자율적이어야 한다는 말은 결국 자기에게 주어진 책임을 하는 건 그 요청을 받은 객체 자신이기 때문에 요청받은 책임을 처리하는 방식은 그 스스로에게 있다는 말이다. 이건 캡슐화라는 개념과도 관련이 있다고 한다. 간단히 정리를 하면 내가 설계한 역할을 가진 클래스들 간에 적절한 책임을 질 수 있게 메서드를 만들고 각 클래스들은 다른 클래스들에게 적절히 요청을 보내고 그 뒤에 처리하는 건 보낸에가 알 필요가 없다는 것이다. 1장 마지막에는 클래스에 대한 오해를 정리하면서 끝내는데, 클래스는 객체지향에서 중요한 구성요소는 맞지만 핵심이라 보기에는 무리가 있다. 그니까 너무 얽매이지 말고 위에서 말한 역할, 책임, 협력들을 우선적으로 생각하라는 거 같다.

2장은 객체에 대해 구체적으로 다루는데 객체가 무엇인지, 어떻게 구성이 되는지를 이야기 해준다.  책에서는 객체를 다음과 같이 정의한다.

객체란 식별 가능한 개체 또는 사물이다. 객체는 자동차처럼 만질 수 있는 구체적인 사물일 수도 있고, 시간처럼 추상적인 개념일 수도 있다. 객체는 구별 가능한 식별자, 특징적인 행동, 변경 가능한 상태를 가진다. 소프트웨어 안에서 객체는 저장된 상태와 실행 가능한 코드를 통해 구현된다.   2장 47page

책에서 상태, 행동, 식별자를 하나씩 예를 들어서 설명해 주는데 간단히 정리하면, 상태는 프로퍼티로 구성이 되고, 프로퍼티는 단순한 값과 다른 객체를 참조하는 링크로 구분될 수 있다. 행동은 객체의 상태에 영향을 주고 행동의 결과는 객체의 상태에 의존한다. 간단한 예시를 들면 크롬 탭에 3개가 있다 근데 여기서 탭 추가를 누르면 4개가 될 거다. 당연한 얘기 같지만 4개가 된 건 3개에서 하나가 추가된 거고 탭 추가란 행동을 통해 상태가 변한 것을 알 수 있다.  뭐 이런 상태에 대해서 흥미롭게 읽은 부분이 있는데, 다음과 같다.

상태를 이용하면 과거의 모든 행동 이력을 설명하지 않고도 행동의 결과를 쉽게 예측하고 설명할 수 있다.
.....
상태를 이용하면 과거에 얽매이지 않고 현재를 기반으로 객체의 행동 방식을 이해할 수 있다. 상태는 근본적으로 세상의 복잡성을 완화하고 인지 과부하를 줄일 수 있는 중요한 개념이다.
2장 48 page

이런 글들을 보면 참 재밌는 거 같다. 대충 느낌으로 알던 개념들을 제대로 인지를 시켜준다고 해야 하나? 아무튼 그렇다.

아 그리고 행동에 대해서도 좀 더 설명하자면, 객체가 행동을 취해서 상태가 변경된다는 것은 행동이 side effect를 초래한다는 것을 의미한다. 부수 효과의 개념을 이용하면 객체의 행동을 상태 변경의 관점에서 쉽게 기술할 수 있다고 한다. 이거 보고 함수형 프로그래밍에서는 반대로 순수 함수들은 이 side effect를 발생시키지 않게 작성한다는 게 갑자기 그냥 생각났다. 

다음으로 식별자에서는 일반적인 값과 객체의 차이와 일반적인 값은 단순한 상태를 비교해서 같은지 여부를 알 수 있는 동등성과 객체는 식별자를 통해 같은지를 파악할 수 있는 동일성에 대해 이야기한다. 

2장 마지막 부분이 가장 흥미로웠는데, 설계를 할 때 상태보다는 행동 위주로 코드를 설계해야 한다고 말한다. 

객체지향 설계는 애플리케이션에 필요한 협력을 생각하고 협력에 참여하는 데 필요한 행동을 생각한 후 행동을 수행할 객체를 선택하는 방식으로 수행된다. 행동을 결정한 후에야 행동에 필요한 정보가 무엇인지를 고려하게 되며 이 과정에서 필요한 상태가 결정된다. 따라서 먼저 객체의 행동을 결정하고 그 후에 행동에 적절한 상태를 선택하게 된다. 
2장 65 page

협력 안에서 객체의 행동은 결국 객체가 협력에 참여하면서 완수해야 하는 책임을 의미한다. 따라서 어떤 책임이 필요한가를 결정하는 과정이 전체 설계를 주도해야 한다고 하는데 이런 걸 RDD라고 한다. '행동이 상태를 결정한다.' 이게 중요하다

마지막으로 의인화와 은유에 대해서 이야기하면서 도대체 왜 저자는 우리가 알던 '객체지향은 현실 세계의 모방'이라는 말이 문제라고 이야기한 지 이유를 말해 준다. 의인화는 간단히 이야기하면 소프트웨어에서의 객체는 의인화가 된 상태로 보면 될 거 같고, 은유는 그렇다면 왜?  일반적으로 객체지향을 가르칠 때 현실 세계의 모방,  현실의 추상화라는 이야기를 많이 하면서 가르치게 됐는지를 설명해 준다. 은유 관계에 있는 실제 세계의 객체의 이름을 소프트웨어 객체의 이름으로 사용하면 표현적 차이를 줄여 소프트웨어 구조를 쉽게 예측할 수 있기 때문에 그렇다고 한다. 그래서 만약 내가 작성하는 객체에 대한 더 좋은 표현이 있다면 차라리 그걸 사용하는 게 더 좋을 수도 있다고 한다.

 

 

 

참고 및 출처: <객체지향의 사실과 오해 역할, 책임, 협력 관점에서 본 객체지향> (조영호 지음, 위키북스 , 2015)