[객체지향의 사실과 오해] 4장 : 역할, 책임, 협력

🙋 들어가며

모든 일에는 일련의 흐름이 존재합니다.

연애를 하고 싶다고 무작정 고백하면 그냥 혼쭐 내는 것과 다를 바가 없습니다.

서로를 알아가는 썸이라는 단계를 밟고 고백을 해야만 비로소 연애를 시작할 수 있습니다.

 

객체지향의 세계에서도 마찬가지입니다.

먼저 객체의 행동과 상태을 고려하는 것은 고백으로 혼내주는 것입니다.

우리는 도메인을 먼저 분석하고 어떤 흐름으로 해결할지 고민하는 것이 중요합니다.

 

이 흐름이 바로 문맥(Context)입니다. 

객체지향 세계에서 객체들은 문맥을 속에서 서로 협력합니다. 

이번 장에서는 바로 문맥에 맞게 협력을 고려하기가 주제이자 핵심입니다.

---

🗣️ 협력 

객체가 협력하는 가장 중요한 이유는 동일한 목적을 이루기 위함입니다.

그렇다면 왜 협력이 중요할까요? 간단한 예로 들어보겠습니다.

 

치킨이 땡기는 야심한 밤, 실수로 배달앱을 눌렀는데 어느새 주문이 완료되었습니다. (글을 작성하던 중 벌어진 일입니다.)

치킨집이 없었다면 우리는 치킨을 먹기 위해서 다음과 같은 일을 했을 겁니다.

• 닭을 사온다.
• 닭을 염지 한다.
• 닭에 튀김옷을 입힌다.
• 기름에 닭을 튀긴다.

하지만 우리는 배달앱에 들어가 수많은 치킨집 중 하나를 고르고 배달해줘라고 요청을 하면 됩니다. 

 

이 예시는 객체지향이라는 패러다임이 등장하기 전과 후를 의미합니다. (이해를 위한 예시일 뿐 좋은 예시는 아닙니다ㅎ)

두 방법 모두 치킨이란 결과물을 받아내지만, 제가 어떤 닭을 사고 어떻게 만드는지와같은 정보는 알 필요 없습니다. 

저는 개발자로 개발이라는 행위만 잘하면 됩니다, 치킨이 먹고 싶다면 단순히 주문하고 먹으면 됩니다.

또, 일반 가정집과 치킨집 중 어느 곳에서 치킨을 만드는 것이 더 적합할까요? 집에서 튀기면 혼납니다 🥹

 

따라서 제가 생각하는 협력이 중요한 이유는 코드가 올바른 곳에 위치할 수 있도록 고민하게 함이라고 생각합니다.

코드가 옳바른 위치에 존재한다면 자연스럽게 코드의 응집도는 높아지게 됩니다.

나아가 뒤에서 언급할 객체의 역할과 책임을 자연스럽게 잘 설정할 수 있다고 생각합니다.

 

협력은 요청이 오면 응답을 함으로 이루어지게 됩니다.

여기서 요청을 받음이 의미하는 바는 받은 대상이 요청을 처리하는데 필요한 지식과 행동을 가지고 있음을 의미합니다.

치킨을 치킨집이 요청하면, 치킨집은 준비된 닭을 가지고 닭을 튀김으로서 받은 요청을 처리하는 것으로 이해하면 좋을 것 같습니다.

---

📚 책임

책임이란 정확하게 무엇을 의미하는 것일까요?

어떤 요청에 대답해 줄 수 있거나 적절한 행동을 할 의무가 있으면 책임을 가진다고 표현합니다.

 

객체의 책임은 아는 것과 하는 것 두 종류로 나눌 수 있습니다.

도메인 로직에서 자주 등장하는 다음과 같은 메서드들을 의미합니다.

// 하는 것 (ex. excute(), run())
public void updateName(String name) {
  this.name = name;
}

// 아는 것 (ex. isXXX(), hasXXX())
public boolean isOk {
  return this.status == Status.OK;
}

책에서는 책임과 메시지의 수준은 같지 않고, 하나의 책임이 여러 메시지로 분할되는 것이라고 주의했습니다.

조금 어려운 말이지만 관점의 차이를 뜻합니다.

 

책임은 한 객체만의 관점에서 이루어지는 것이고, 메시지는 적어도 둘 이상의 객체가 필요합니다.

다시 말하면, 메시지는 이름 그대로 보내는 쪽과 받는 쪽이 필요하므로 조금 더 큰 관점에서 이야기를 하는 것입니다.

 

책에서 언급한 이번 장의 주제는 협력이라는 문맥입니다.

메시지가 분할된다는 말은 보내는 사람이 여럿일 수 있음을 의미하는 것 입니다. 

어떤 책임을 수행하는 객체에게 다양한 객체가 요청함을 의미하는 것이죠.

 

추가적으로, 언어적인 관점에서 메시지를 다르게 바라볼 수도 있을 것 같습니다.

메시지란 코드에서 어떤 것을 의미하는 것일까요?? 저는 메시지란 메서드의 선언부라고 생각합니다. (일부 언어 기준)

 

오버로딩을 지원하는 언어에서는 같은 이름을 가진 다양한 메서드를 만들 수 있습니다.

따라서 메서드마다 파라미터와 리턴타입이 달라질 수 있으므로 다양한 행동이 보장할 수 있습니다.

책임은 요청에 따라 적절한 행동 하는 것입니다. 그러므로 오버로딩을 통해서 달라지는 구현부와 동일합니다.

메시지와 비슷한 방식으로 요청은 메서드의 이름 그 자체입니다. 정리하면 다음과 같습니다.

---

👮‍♀️ 역할

역할은 앞선 두 개념보다는 조금 더 친숙할 거라고 생각합니다.

바로 예시로 들어가 개발자라는 역할에 대해서 생각해 보겠습니다.

 

개발자의 일은 여러 가지가 존재하는데, 대표적으로 코드 짜기, 설계하기가 있을 것 같습니다.

이런 일들은 월급이라는 궁극적인 목표를 위해서 꼭 수행해야 하는 것들입니다. 

수행하면서 생기는 결과물은 동일하거나 비슷하며, 처리하는 방식은 조금씩 차이가 있을 수도 있습니다.

 

이 일을 수행하는 대상이 단순히 한 명만 존재할까요? 아닙니다, 다른 개발자가 와서 제 일을 대신할 수도 있습니다.

이처럼 개발자가 코드 짜기(책임)라는 일을 수행하는 것은 역할을 수행한다는 것과 동일합니다.

 

역할이 중요한 이유가 여럿 존재하겠지만, 저는 유연함이 가장 중요하다고 생각합니다.

역할을 다르게 표현하면 협력에서 똑같은 기능을 한다면 누구라도 대신할 수 있다입니다.

 

앞서 읽었던 1장에서부터 역할은 대체 가능성을 가진다고 했습니다.

역할을 대체할 수 있다는 말은 동일한 메시지를 이해할 수 있다는 뜻이고 이는 동일한 책임을 가진다와 동일합니다.

따라서 동일한 책임을 가졌기 때문에 대체할 수 있다고 말할 수 있는 것입니다.

---

😋 지극히 개인적인 블로그지만 훈수와 조언은 제 성장에 도움이 됩니다 😋