객체 지향의 사실과 오해 <Part 1.>

조운희·2021년 8월 14일

시작하기 앞서

이 포스트는 요즘 읽고 있는 조용호님께서 지으신 '객체지향의 사실과 오해' 라는 책의 나만의 느낀 점, 정리해야 될 부분들을 기록하기위해서 작성하였습니다.

시간나면 읽어야지 라는 마인드로 책을 읽다보니 중간 중간 텀이 너무 길어졌습니다. 그러다보니 앞의 내용일 까먹게 되고, 첫장만 두 세번 읽게 되었습니다... 그러다가 벨로그가 생각나게 되었고, 다시는 까먹지 않도록 기록하려 합니다.
~~블로그 시작 글의 내용이 무색하게 첫 포스팅이 매우 늦어지게 되었습니다... 저의 열정은 식어버린듯 합니다.~~

책을 읽게된 이유

요즘에 스프링 프레임워크를 공부하기위해 인프런에서 김영한님의 강의를 수강하고 있습니다. 해당 강의를 시작하면서 스프링의 발전하게된 이유를 설명해주셨는데요, 설명의 중간 중간에 객체 지향에 대해서도 설명해 주셨습니다. 그리고 마지막으로 이 책을 소개해주셨는데요, 저는 학교를 다니면서, 현재 재직을 하면서도 C만을 다뤄 객체지향에 대한 개념이 부족하다고 느끼고 있었습니다. 그래서 강의를 수강하며 시간 날때마다 조금씩 읽고 있었습니다.

내용 정리

Chapter 1. 협력하는 객체들의 공동체

객체지향이라고 불리는 새로운 세상의 문을 연 대부분의 사람들은 "객체지향이란 실세계를 직접적이고 직관적으로 모델링할 수 있는 패러다임"이라는 설명과 마주하게 된다.

... 중략 ...

아쉽게도 실용적인 관점에서 객체지향 분석, 설계를 설명하기에는 적합하지 않다.

위의 문구로 해당 챕터를 시작하고 있습니다. 제가 전문적으로 객체지향에 대해서는 공부하진 않았지만, 자바 수업을 들었을 때, 붕어빵과 붕어빵틀 설명으로 클래스와 객체, 객체지향에 대해서 간단하게 설명을 들었었습니다. 더불어 실세계의 모방이라는 설명도 머릿속에 남아있었지요. 하지만 이 부분을 꼬집으며 시작하여 당황하였습니다. 동시에 그럼 뭔데? 라는 생각도 들었습니다.

이 챕터의 내용에 따르면, 객체지향은 고객의 니즈를 만족하며 새로운 세계를 창조하는것이라고 합니다. 간단하게 전구를 예시로 들면, 현실 세계의 전구는 스스로 전원을 키거나 끌 수 없지만, 우리가 구현할 객체지향의 세계에서는 요청을 받아 스스로 전원을 키거나 끌 수 있게 됩니다.

이런 괴리가 있음에도, 사람들은 왜 실세계의 모방이라는 개념을 사용하여 객체지향을 설명할까요? 그것은 객체지향의 철학적인 관점을 이해하는데는 도움이 되므로 많은 사람들이 객체 지향을 설명할 때 사용하는 관용적인 문구가 되었다고 합니다. State, behavior를 캡슐화하여 사용하는 객체들의 자율성을 설명하기 유리하기 때문이라 합니다.

이 챕터에서는 우리가 알고 있는 객체 지향의 개념 대신, 역할, 책임, 협력의 관점으로 객체지향을 바라보는 방법에 대해서 설명하고 있습니다. 이 개념들이 앞으로 제가 읽게될 챕터에서의 기본 베이스이므로, 이 포스트에서 잘 정리하려고 합니다.

역할과 책임

그럼 역할은 무엇일까?

역할은 공동의 목표달성을 위해 해야하는 일들을 묶어놓은 것으로 이해하였습니다. 각 사람들은 공동체안에서 각자만의 역할들이 있고, 자신에게 할당된 일들을 책임지고 수행하며 공동의 목표를 달성한다고 합니다.

손님에게는 커피를 주문하며 돈을 내고, 커피를 받아가는 역할이 있고, 캐셔는 주문을 받고, 바리스타에게 제조 요청을 하고, 전달 받은 커피를 손님에게 전달하는 역할이 있습니다. 바리스타도 비슷하게 제조 요청에 따라 커피를 제조하여 전달하는 역할이 있습니다. 각 구성원들은 본인들의 역할에 책임지고 수행하며 공동의 목표를 달성합니다.

객체지향의 세계에서도 동일하게 각 객체에게 할당된 역할에 충실하여 어플리케이션의 기능이라는 목표를 달성합니다.

책임이란?

제가 이책을 읽고 이해한 바로는 역할 수행을 위한 일들중 하나라고 이해하였습니다. 손님을 예로들면, 커피를 주문하는 책임, 주문하고 결제할 책임이 있는것이지요. 그래서 각 책임들을 한데 묶으면 역할이 되는것이라고 이해하였습니다.

역할과 책임이 주는 중요한 개념

여러 사람들이 동일한 역할을 수행할 수 있다.
- 커피를 주문하러온 손님 입장에서는 캐셔가 누구인지, 바리스타가 누구인지 관심이 없습니다. 또한 만약 어떤 캐셔가 그만둔다면, 다른 사람들 고용하여 캐셔의 역할을 부여하면 됩니다.
역할은 대체 가능성을 의미한다.
- 상기 설명과 동일한데요, 손님 입장에서는 어떤 캐셔이든 요청하더라도 문제가 되지 않는다는 내용입니다.
책임을 수행하는 방법은 자율적으로 선택할 수 있다.
- 바리스타는 본인들의 커피를 내리는 방법으로 커피를 제조합니다. 어떤 바리스타는 라떼 아트를 하기도 하고, 어떤 바리스타는 얼음을 더 많이 넣어줄 수 도 있습니다. 중요한 점은 커피를 제조하는 요청을 받더라도 바리스타 역할을 수행하는 사람들마다 자신들만의 방식으로 요청을 처리합니다. 이를 다형성이라고 합니다.
한 사람이 동시에 여러 역할을 수행할 수 있다.
- 보통 아무 카페에 들어가면, 캐셔와 바리스타의 역할을 동시에 수행하는 사람들이 대부분입니다.

책임과 역할을 살펴보았는데, 제가 이해한 바로 요약하자면,

역할 : 공동의 목표를 달성하기위한 여러 단계의 일들의 집합
책임 : 역할 수행을 위한 일들중 하나

책에는 커피,손님, 바리스타의 예시로 자세히 설명이 되어있지만, 제 식견이 짧아 이정도로 밖에 이해하지 못했습니다... 아쉬움을 뒤로하고, 다음으로 협력을 살펴보도록 합시다.

협력

협력을 살펴보자

이 책에서는 사람들이 공동의 목표를 달성하기 위해 구성원들 각각이 서로 도움을 요청하고 응답하며 협력하듯, 객체들도 동일하게 어플리케이션의 기능을 수행하기 위해 Message형태로 각각의 객체들이 서로서로 요청과 요청을 처리한 뒤, 응답하며 협력한다고 설명하고 있습니다. 자세히 설명하기 위해 커피를 주문하는 손님, 캐셔, 바리스타를 예로 설명을 해주고 있습니다.

1. 손님은 캐셔에게 커피를 주문(요청)합니다.
2. 캐셔는 바리스타에게 커피 제작을 요청합니다.
3. 바리스타는 커피를 제조하고 캐셔에게 커피를 전달(응답)합니다.
4. 캐셔는 전달받은 커피를 다시 손님에게 전달(응답)합니다.

상기 과정에서 손님, 캐셔, 바리스타를 객체로, 요청, 응답을 Message 형태로, 요청의 처리를 Method로 바꿔서 본다면, 각 객체들이 어떻게 협력하여 어플리케이션의 기능을 구현하는지 알 수 있습니다.

협력속에 사는 객체

지금까지 객체지향의 윤곽을 결정하는 역할, 책임, 협력을 살펴보았습니다. 하지만 실제로 협력에 참여하는 주체는 객체지요. 즉, 객체지향 패러다임의 중심에는 객체가 있으므로, 이 객체에 대해서 살펴봅시다.

객체와 자율성

객체
많은 사람들이 객체를 상태(state), 행동(behavior)을 함께 지닌 실체라고 정의합니다. 다시 풀어보면, 객체가 협력에 참여하기 위해 어떤 행동을 해야 한다면, 그 행동을 하는데 필요한 상태도 함께 알고 있어야 한다는것을 의미합니다. 이러한 과정중에 객체의 자율성은 어떻게 보장할까요?

자율성
객체의 자율성은 내부/외부를 구분지으며 보장되기 시작합니다. 객체의 내부에서 스스로 상태를 관리하고 외부에서의 간섭을 막아야 하고, 접근을 허락한 수단을 통해서만 외부의 객체와 소통해야한다고 합니다. 외부의 요청(Message)과 요청을 처리하기 위한 구체적인 방법(method)을 분리하여 객체의 자율성을 높이는 것입니다. 요약하면, 다른 객체가 무엇을 하는지는 알 수 있지만, 어떻게하는지는 몰라야합니다.

따라서 이 협력의 과정중에 상태를 기반으로 객체들은 스스로 판단하여 어떤 행동을 취할지를 결정하며, 그 행동을 통해 다른 객체와 협력하여 공동의 목표를 달성합니다. 이러한 자율성이 보장된 상태로 협력을 하는 객체들 덕분에 우리는 유지보수가 쉽고, 재사용이 용이한 시스템을 구축할 수 있게된다고 합니다.

협력안에서 갖춰어야할 객체의 덕목

협력을 하기위해선 객체는 2가지 덕목을 갖춰야한다고 합니다.

객체는 협력적이어야한다.
- 각 객체는 요청에 열려있어야 하며, 필요에 따라선 다른 객체에게 도움을 요청할 수 있어야 한다. 하지만 열려있다고 수동적으로 동작하는것은 아니며, 필요하다면 응답을 하지 않을 수 있다.
객체는 충분히 자율적이어야한다.
- 객체는 스스로 행동을 결정하고 책임을 져야한다. 다른 객체의 요청을 본인의 판단하에 응답 여부와 어떻게 응답할지 결정할 수 있어야 하며, 필요하다면 요청을 어떤 객체에게, 어떻게 할 것인지도 결정할 수 있어야 한다고 합니다.

객체지향의 본질

역할, 책임, 협력을 알아보았으며, 협력속에서 객체가 취해야할 스탠스도 알아보았습니다. 다시 한번 정리하자면,

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

객체를 지향하라

많은 사람들이 객체 지향이라는 단어를 들으면 클래스를 생각하게 됩니다. 클래스는 객체지향의 중요한 구성요소인것은 분명하지만, 객체 지향의 핵심을 이루는 중심 개념이라고 말하기는 힘듭니다. 간단한 반례로 이 책에서는 자바스크립트를 제시하고 있습니다. 또한, 클래스를 강조한 프로그래밍 관점은 캡슐화를 저해하고 클래스간 강하게 결합시킨다고 합니다.

(어떤 클래스를 상속받을지, 구현할 지등에 초점이 맞춰진다면 역할, 책임과 거리가 멀어진 관점에서 설계하게 되겠구나 라고 이해하였습니다.)

훌륭한 객체지향 설계자가 되기 위해서는 클래스의 관점에서 메세지를 주고 받는 객체의 관점으로 사고의 중심으로 전환하여야 한다고 합니다. 클래스는 협력 관계를 코드로 옮기는 것 뿐, 핵심이 아니다라고 설명해주시고 있습니다.

느낀점

지금까지 챕터1. 협력하는 객체들의 공동체를 살펴보았습니다. 처음 접하는 내용도 많았고, 찾아봐야하는 내용도 많았기 때문에 읽는데 좀 오래걸렸습니다. 어차피 나만을 위해서 포스팅하기로 했지만, 그래도 혹시 몰라 잘 써보려고 했는데,,, 마음처럼 쉽지 않네요.

복습하기 위해서 전체 글을 다시 읽기는 좀 그런거 같아서 외워야할 점만 정리해보려 합니다.

클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중해야 하며, 객체 지향은 말 그대로 객체를 지향하는 것이지 클래스를 지향하는것이 아닙니다. 우리는 훌륭한 객체지향 시스템을 설계하기 위해서는, 공동의 목표에서 적합한 역할과 책임을 분리해야 하며, 이를 적절하게 객체에게 할당해 주어야 합니다. 동시에 각 개체간 어떤 메세지를 주고 받을지를 생각하고 협력의 품질을 올리는데 집중해야 합니다. 또한, 자율성을 어떻게 보장할 것인지도 고민해야합니다.

이상입니다.

조운희

unhee.jo

이전 포스트

블로그 시작!

다음 포스트