객체지향의 사실과 오해를 읽고

객체지향의 사실과 오해를 읽게 된 계기

언젠가 이런 말을 들어본 적이 있다.
‘Java에서는 Primitive Type 이 존재하기 때문에 순수한 객체 언어가 아니라 객체지향언어로 분류된다.’
이 말을 듣고 순수한 객체 언어(Pure Object Language)를 찾아 보게 되었다.

Java 에서는 int, long, char, double 같은 원시타입이 존재하며. 이는 클래스로 정의되어 있지 않다.
따라서 순수 100% 객체로 이루어진 언어가 아니었던 것이다.

참고) Python 은 순수 객체 언어이다.

print(type(2))
print(type("string"))
print(type([]))
print(type({}))
print(type(()))

<class 'int'>
<class 'str'>
<class 'list'>
<class 'dict'>
<class 'tuple'>
// python 에서는 모든 것이 클래스로 정의되어 있다.

Java를 순수 객체 언어가 아니라는 것을 알게 되면서 또 다른 의문이 생겼다.

• 클래스는 객체와 동치인가?,
• 클래스가 존재한다면 객체지향인가?
• 절차지향과는 무엇이 다르지?
• 객체는 무엇인가?

개발과 관련된 오픈채팅방에선 가끔 건설적인 토론이 벌어진다.
마음속 품고있던 객체지향이란 무엇인가? 에 대해 다른 사람들의 생각이 궁금해졌고,
이런 저런 대화를 나누던 중 드디어, ‘객체지향의 사실과 오해’ 라는 책을 추천받게 되었다.

책의 서문을 보자마자 이 책은 반드시 읽어야 겠다는 생각이 들게 만든 문구가 있었다.
‘객체지향이란 무엇일까요? 이 질문에 여러분은 뭐라고 답하시겠습니까?’

부끄러운 얘기지만 내가 Java 를 처음 배울 때, 클래스를 어떻게 설계해야 하는가에 초점이 맞춰져 있었고,
객체지향 == 붕어빵틀 & 붕어빵 이라는 굉장히 고전적인 이론으로 결론짓고 살고 있었다.

객체지향의 오해

객체지향을 처음 접할때 ‘실세계를 직접적이고 직관적으로 모델링 할 수 있는 패러다임’ 이라는 설명과 마주하게 된다.
나도 객체지향언어를 처음 배울 때, ‘실세계에 있는 것들을 추상화하여 소프트웨어 세계에서 다루는 언어’ 정도로 배웠던 것 같다.

하지만 이 부분에서 가장 큰 오해가 있었다.
실제로 애플리케이션을 개발하면서 객체에 직접적으로 대응되는 실세계의 사물을 발견할 확률은 그다지 높지 않다.

객체지향의 목표는 실세계를 모방하는 것이 아니다.

이런 부분이 나를 비롯한 많은 개발자들이 객체지향에 대해 오해하고 있었던 점이다.

물론, 실세계를 모방하여 객체지향을 설명하려는 시도는 객체지향을 처음 접하는 시점에서는 매우 효과적이다.
하지만 실무적인 관점에서는 객체지향이 실세계를 모방한다는 것이 다소 부적합하다.
노련한 객체지향 전문가들은 본능적으로 이런 사실을 인지하고 있다.

객체지향의 사실

책의 상당히 초반 부분인 ‘객체지향의 본질’이란 챕터에서
책의 서문에서 던졌던 “객체지향이란 무엇인가?”에 대한 필자의 답을 찾을 수 있다.

• 객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 바라보고 객체를 이용해 시스템을 분할하는 방법이다.
• 자율적인 객체란 상태와 행위를 함께 지니며 스스로 자기 자신을 책임지는 객체를 의미한다.
• 객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력한다. 각 객체는 협력 내에서 정해진 역할을 수행하며, 역할은 관련된 책임의 집합이다.
• 객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택한다.

책의 상당히 초반 부분에 핵심적인 내용이 나오기 때문에, 이미 객체지향이 무엇인지 나름의 정의를 가지고 있고,
조영호님의 생각과 어느정도 일치한다면, 뒤에 나오는 이상한 나라의 엘리스 비유나, 앞에 있었던 커피 공화국 예시가 술술 읽힐 수 있다.

생각해보자

‘객체지향이란 무엇인가?’ 라는 질문을 봤을 때 가슴이 쿵쾅거렸다.
마치 알고보면 아무것도 모르는 나의 머리속 지식들이 발가벗겨진 기분이랄까..

한편으론 무시당한 것 같은 느낌이 들면서 분노와 비슷한 감정이 치밀어 올랐다.
그렇게 읽기 시작하면서 점점 필자의 생각과 주장에 설득되었다.

우아한 테크 캠프에서 기억에 남는 강의 중 하나 였던 ‘레거시 리팩토링’ 미션에서
소프트웨어의 존재 가치에 대해 다루었던 적이 있다.
소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다.

왜 이게 갑자기 생각났던 건지는 잘 모르겠지만,
애플리케이션을 개발하는 목적과 객체지향이 맞물려서 생각하게 되었다.

1. 소프트웨어의 본질은 해당 소프트웨어의 사용자를 위해 도메인에 관련된 문제를 해결하는 능력에 있다.
2. 객체지향 소프트웨어는 사용자의 문제를 해결하는 기능을 객체들의 협력을 통해 제공한다.
3. 객체는 이 때 자율적인 상태와 행위를 가지며, 이를 위해 적절한 책임을 부여받는다.

이러한 관점에서 객체지향의 4가지 특성과 SOLID 원칙이 왜 생겨 났는가? 에 대해 다시 생각할 수 있는 기회가 되었고,
책에서도 적절한 역할과 책임을 부여하기 위해 4가지 특성(추상화, 상속, 캡슐화, 다형성)을 어떻게 적용해야 하는 지,
잘 설명되어 있었다.

하지만, 나처럼 객체지향에 대한 경험이 부족하다면 이 책을 단순히 읽었을 때에는 그 본질을 정확히 이해하기가 힘들것이다.
책의 후반부에 코드로 직접 바람직한 객체지향을 어떻게 코딩해야 하는 지 나와있는데,
그 부분을 먼저 보고 앞에 커피 공화국이나 이상한 나라의 엘리스 비유를 보면서
머리속으로 뇌코딩 해보는 것도 이 책을 이해하는 데 좋은 방법인 것 같다.

또한 책의 서문에 보면, 책을 집필하게 된 동기에 대해 나오는데,
작성하고 계셨던 다른 책(오브젝트)을 이해하는 데 필요한 개념과 배경 지식을 제공하고 싶었기 때문이라고 나와있다.
역시 무엇이든 힘을 빼고 해야 대박이 나나보다..

가끔 드라마나 책을 보면서, ‘아 이건 주기적으로 정주행 해야되겠다.’ 라는 작품이 있다.
나에겐 이 책이 딱 그러했다.