Jello's development blog

Jello's development blog

책 [객체지향의 사실과 오해]

객체지향의 사실과 오해

친구가 추천해줘서 읽어보았다. 책이 그렇게 두껍지 않고, 글자 크기도 다른 전공책보다 상대적으로 커서 금방 읽겠지 하고 천천히 읽다가 거의 한 달만에 겨우 끝냈다. 코드보다는 개념 위주이고, UML과 이해를 돕는 삽화가 많아서 지루하지 않게 읽을 수 있었다. 깊게 배운 적은 없지만, 내가 지금까지 배워왔던 객체지향의 설계 방법과 원리를 깨고 새롭고 강력한 패러다임을 가르쳐준 책이다.

객체지향 하면 많은 사람들이 클래스를 제일 먼저 떠올릴 것이다. 실제로 많은 책이나 강의가 클래스가 가장 중요한 개념이라고 가르치고 있고, 객체지향 언어를 처음 입문할 때에 절차지향과 다르게 배우는 것이 바로 클래스라는 개념이기 때문이다. 나도 이 책을 읽기 전에 그랬고, 읽고 나서인 지금도 여전히 객체지향 하면 클래스부터 떠오른다. 하지만 정말 객체지향이 의미하는 것이 무엇인지는 알게 되었다. 클래스는 그저 객체지향을 실현시킬 수 있게 도와주는, 객체의 정보를 명시해놓은, 객체를 찍어내는 도구에 불과하다. 클래스를 쓰기만 한다고 해서 객체지향이 아니고, 클래스를 쓰지 않는 언어(Javascript)에도 객체지향을 적용할 수 있다.

이 책에서는 시스템을 설계할 때에 책임 주도 설계(Responsibility-Driven Design)라는 방법론을 소개하고 있다. 모든 것은 책임과 협력에 따라 설계되어야만 한다는 것이다. 객체지향 시스템에서 객체는 고립된 존재가 아니며, 시스템의 더 큰 목표를 달성하기 위해 다른 객체와 협력하는 사회적인 존재다 (객체지향의 사실과 오해, 131). 결국 객체지향은 시스템이 사용자의 궁극적인 목표를 달성할 수 있도록 책임을 분배한 후, 각 객체에게 물려주어 협력함으로써 그 목적을 이루도록 하는 구조로 설계되어야 한다. 이렇게 되면 시스템은 기능 변경에 대응하기 쉬워지고 확장성있게 설계될 수 있다.

객체는 무조건(다른 객체와 협력해서라도) 다른 객체 혹은 사용자로부터 명령받은 역할을 수행해야 하는데, 이를 수행하는 방법에 대해서는 자율성을 보장받고 은닉되어야 한다(캡슐화). 즉, 각 객체의 내부적인 프로세스가 시스템 전체의 프로세스에 독립적이어야 한다는 말이다. 어떤 객체가 동일한 메시지를 받을 수 있는 다른 객체로 대체되어도 전체 시스템에는 영향을 주지 않는 구조가 되어야 한다.

객체를 설계할 때에는 그 객체가 가지고 있어야 하는 상태(변수)가 아닌 외부적으로 어떤 행동을 해야하는지(역할, 메소드)부터 생각해야 한다. 객체가 어떤 행동을 해야할지 정해지지 않았는데 객체가 무엇을 알아야 하는지부터 정한다는 것은 비효율적이고 잘못된 설계를 초래할 수 있다.

개인적으로 CS관련 지식이 부족하다고 생각하고 있는데, 부족한 부분 중 일부분을 채워준 것 같아서 만족스러웠다. 요즘에 개발자의 기본 소양이라고 할 수 있는 이러한 지식들이나 알고리즘 등의 필요성에 대해서 말이 많은데, 더 크게 성장하기 위해서는 이런 것들이 뒷받침되어야한다고 생각한다.