[객체지향의사실과오해] 05 - 책임과 메시지

옛날에 책 읽으면서 작성했던 건데 오랜만에 글 올릴 겸... 시리즈 마무리는 하면 좋을 것 같아서 올리려고 한다 :D

 

---

 

✔️ 자율적으로 행동하는 객체

앞선 챕터에서 늘 강조했던 것처럼, 객체는 자율적으로 행동이 가능하다.

이때, 객체가 행동하는 유일한 이유는, 다른 객체로부터 요청을 수신했기 때문이다.

여기서 요청을 처리하기 위해 객체가 수행하는 행동을 ‘책임’이라고 하며, 자율적인 객체란 스스로의 의지와 판단에 따라서 각자 맡은 책임을 수행하는 객체를 의미한다. 객체가 자신에 의지에 따라서 책임을 자율적으로 수행한다는 게 무엇을 의미하는 걸까? 

 

쉽게 생각하기 위해 다시 고양이 스낵바 예제를 꺼내보자.

고양이 스낵바의 인기가 폭발하면서 아침부터 많은 음료 제조 요청이 들어왔다.

이때 알바냥에 셰프냥에게 ‘카페라떼 10잔, 아메리카노 10잔’을 제조를 지시한 상황을 생각해보자.
셰프냥이 카페라떼를 먼저 만들고 아메리카노를 만들든, 아메리카노를 만들고 카페라떼를 만들든 상관이 없어진다. 그저 어떻게든 단순히 주문한 목록에 대해서 수행을 완료하기만 하면 되는 것이다.

하지만, 너무나도 바쁜 아침에 주문이 많이 들어온 알바냥이 잔뜩 심술이 난 나머지, 셰프냥에게 아메리카노 3잔을 만들고 카페라떼 5잔을 만든 다음에, 다시 아메리카노 7잔을 만들고 카페라떼 5잔을 만들어 달라고 했다 생각해보자.
이러한 요청은 셰프냥에 선택할 수 있는 자유를 지나치게 제한한 것이며, 자율적으로 책임을 수행할 수 없도록 만든 것이다.

물론, 역으로 너무 추상적이어도 좋지 않다.

손님냥이 주문한 아메리카노, 카페라떼 10잔씩을 단순히 커피 20잔을 만들어달라고 했다 생각해보자.

셰프냥은 수많은 커피 메뉴 중에서 어떤 커피를 만들어야 하는지 전혀 알 수 없게 된다.

 

즉, 우리는 어느 정도의 자율성을 보장할 수 있는 추상적인 책임을 주면서, 동시에 의도를 알 수 있도록 충분히 구체적이어야 한다.

이와 같은 자율적인 책임은 객체가 수행할 행위를 ‘어떻게’ 할지 지정하는 것이 아닌, ‘무엇’을 할지 지정해야 한다는 것이다.

 

객체는 다른 객체로부터 전송된 요청을 ‘수신’해야만 행동을 시작하며, 결국 외부로부터 어떠한 자극이 전달되면 본인에게 할당된 책임을 수행하기 시작하는 것이다. 우리는 이러한 자극을 ‘메시지’라고 부르며, 메시지는 객체가 행동할 수 있도록 만드는 유일한 방법이다.

---

✔️ 메시지와 메서드

하나의 객체는 메시지를 전송하여 다른 객체에 접근하며, 이때 메시지의 argument를 통해 처리를 위한 추가 정보를 제공할 수 있다.
즉, 하나의 메시지 전송은 메시지의 이름과 인자, 그리고 수신자의 조합이 된다.

 

메시지를 전달받았다면, 수신자는 본인이 책임질 수 있는 행동인지 확인한다.

해당 메시지에 대해서 어떻게 행동할지는 송신자도 알 수 없으며, 외부에 공개된 것은 단순히 메시지 자체일 뿐이다.

우리가 앞에서 이야기 했던 내용을 정리해보자면 다음과 같다.

1. 송신자는 메시지를 전송한다.
2. 수신자는 메시지를 받아 처리할 방법을 자율적으로 선택한다.

여기서, 수신자가 내부적으로 메시지를 처리하기 위해 선택하는 방법이 ‘메서드’이다.

기본적으로 객체는 본인이 처리할 수 있는지에 대한 여부를 확인하고, 처리가 가능하다면 어떤 식으로 처리할지 메서드를 선택하게 된다.

 

---

✔️ 다형성

다형성이란, 서로 다른 객체가 동일한 메시지에 대해서 다르게 반응하는 것을 의미한다. 이는 수신자가 메시지를 자유롭게 처리할 수 있기 때문에 (어떻게 처리할지 정해져 있지 않기 때문에) 생기는 특성이라고 볼 수도 있다.

 

예를 들어, 알바냥이 ‘아메리카노 10잔, 카페라떼 10잔’을 만들라는 주문을 전달했을 때 주방에서는 무슨 일이 일어날까?

수석 셰프냥은 뛰어난 실력으로 인해 커피를 만들 때 늘 아메리카노를 먼저 만들고, 라떼아트를 가득 담은 카페라떼를 만든다. 
하지만, 신참 셰프냥은 그저 열심히 아메리카노랑 카페라떼를 만든다. 

우리가 카페를 갔을 때를 생각해보자. 카페라떼에 라떼아트가 있든 말든, 그저 카페라떼는 카페라떼로 받아들일 것이다.

알바냥 입장에서도, 어떤 방법으로 커피를 만들든 그저 아메리카노 10잔과 카페라떼 10잔을 받으면 되는 것이다.

 

다형성의 개념에 대해서 다시 생각해보자.

다형성은, 동일한 역할을 수행할 수 있는 객체 사이의 ‘대체 가능성’을 의미하기도 한다.

예를 들어, 수석 셰프냥이 아파서 알바냥의 주문을 받지 못한다면?

신참 셰프냥이 나와서 충분히 커피 주문을 처리할 수 있게 되는 것이다.

어떤 셰프냥이든, 그저 커피만 만들 줄 알면 되는 것이니까!

이러한 다형성의 이점은, 수신자의 종류를 캡슐화를 할 수 있다는 것이다.

알바냥의 입장에서는 내부적으로 어떤 셰프냥이 요리를 하든 그저 ‘커피를 만들 줄 아는’ 고양이라면 충분히 협력할 수 있으며, 셰프냥이 아니더라도 점장냥이 나와서 커피를 만들어 낼 수도 있는 것이다. (물론, 고양이가 아니어도 된다. 그저 커피를 만들 줄만 알면 되는 것이다!)

다형성을 잘 활용하게 된다면 메시지에 대한 결합도를 낮출 수 있기 때문에,

유연하고 확장성과 재사용성이 높은 객체 지향의 특징을 만족할 수 있게 될 것이다.

---

✔️ 메시지의 힘

앞서 다형성이 모든 걸 책임지는 것처럼 말했지만, 실질적으로는 메시지가 송-수신자 사이의 결합도를 낮추기 때문에 만들어진 마법이었다.

생각해보자, 우리는 '커피를 만들어 줘' 라는 메시지를 통해서 두 고양이들이 소통한 것을 확인할 수 있었다.

송신자는 오직 메시지만 바라보고, 수신자 역시 메시지만 바라보며 유연하고 확장 가능하면서 재사용이 용이하도록 만드는 것이다.

기본적으로 코드를 작성할 때 많이 하는 실수가, 데이터를 위주로 생각하면서 협력이 아닌 객체 내부의 데이터 구조를 먼저 생각하고, 데이터 조작에 필요한 연산들을 나중에 고려하는 것이다. (필자는 이 대목에서 굉장히 찔렸다. 필요한 기능을 먼저 나열하고, 해당 기능에 짜맞추면서 코드를 작성하는 경우가 굉장히 많았으니까.)

이렇게 데이터 중심으로 설계를 하게 되면, 객체의 자율성을 저해시킨다. 내부, 외부에서 자유롭게 쓰이는 필드나 메서드가 생기게 되고, 이로 인해 외부에서 자유롭게 해당 데이터를 사용하게 되면서 객체가 자신의 의지에 따라서 판단하기 어려워지기 때문이다.

 

우리는 협력 관계에서 다른 객체에게 어떤 것을 제공하고, 어떤 것을 얻을 수 있는지 판단할 때 좋은 객체 지향적 설계를 할 수 있다.

즉, 결과적으로 나무를 보는 게 아니라 ‘협력 관계’ 라는 숲을 바라봐야 하는 것이다.

---

✔️ 책임 주도 설계

객체가 본인에게 할당된 책임을 수행해야 하는데, 본인에게 없는 정보가 필요하다면 외부 객체에게 메시지를 전송하여 물어봐야 한다.

예를 들어, 손님냥이 알바냥에게 샌드위치 10개를 사고 싶다고 말했는데, 재고가 2개밖에 없는 상황이라면?

나머지 8개의 샌드위치를 손님냥에게 주기 위해서는 얼마나 기다려야 하는지 알바냥이 가지고 있는 정보로는 알 수 없다.

이때, 알바냥은 샌드위치를 만드는 셰프냥에게 얼마나 기다려야 하는지 물어볼 수 있다.

게임 이미지를 참고하자면... 셰프냥은 아마 샌드위치 1개 만드는데 4초가 걸릴 테니 총 32초 정도가 걸릴 것이다 (?)

각 객체들이 적절한 책임을 가지고 있다면, 이러한 상황에서 어떤 객체에게 질의를 해야 할지 쉽게 판단할 수 있게 된다.

🌱 결과적으로 책임 주도 설계는 객체들 간의 주고받는 메시지를 기반으로 적절한 역할과 책임, 협력을 발견하는 것이다. 
이때, 도움이 필요한 객체는 메시지를 결정하고, 해당 메시지를 처리하기에 적합한 객체를 선택할 수 있다. 
메시지는 수신자가 해야 하는 책임을 결정한다.

 

What / Who 사이클

앞서 언급한 책임 주도 설계를 잘 활용하기 위하여, What-Who 사이클을 사용할 수 있다.

이는 객체 사이의 협력 관계를 설계하기 위해, 어떤 행위 (what)를 수행해야 하는지 결정한 다음, 누가 (who) 그 행위를 수행할 것인지 결정하는 것이다. 여기서 what은 메시지, who는 이를 처리할 객체이다.

중요한 점은, what을 먼저 설정함으로서 어떤 객체가 어떤 기능을 가지고 있는지 먼저 판단하지 않는다는 것이다. 내가 필요한 행위를 생각하고, 이에 대해 처리할 수 있는 객체를 선택한다는 점이다. 위와 같은 사이클을 반복하게 되면, 객체의 인터페이스를 구성할 수 있게 된다.

 

만약, 알바냥이 손님냥에게 질문을 들었을 때 아무 생각 없이 ‘흠… 나보다 오래 알바한 선배 알바냥이 알겠지?’ 라는 생각으로 선배냥에게 여쭤봤다고 생각해보자. 이는 메시지를 먼저 생각하지 않고, 선배 알바냥 (Who)에게 먼저 물어봤기 때문에 What/Who 사이클을 위반하게 된 것이다. 항상 목적을 먼저 생각하고, 이에 대한 객체를 할당하자.

 

묻지 말고 시켜라! (= 디미터의 법칙)

What / Who 사이클에서 What을 결정했다면, 어떤 객체가 이를 수신할지 모르기 때문에 해당 객체에 대해서 물어볼 수가 없다. 그저 내가 보낸 메시지를 잘 처리하겠지? 라는 믿음으로 메시지를 전송하게 될 것이며, 이로 인해 객체는 스스로 처리하는 방법을 고안할 수 있으니 자율성이 더 높아지게 된다. 

또한, 해당 객체에 대한 구체적인 정보를 알 수 없기 때문에 유연성과 확장 가능성 역시 증가한다.

우리는 그저 메시지를 처리할 수 있는 객체를 찾을 뿐이니까!

 

🌱 메시지가 어떻게 해야 하는지 지시하지 말고, 무엇을 해야 하는지 요청하라.
메시지를 믿게 되면 자율적인 책임도 함께 따라오게 된다.

 

---

✔️ 객체 인터페이스

일반적으로 인터페이스는 다음과 같은 특징을 가진다.

- 내부 구조나 동작은 알 필요 없이 겉으로 드러나는 사용법으로 쉽게 사용이 가능하다.
- 내부 구조나 작동 방식을 변경하더라도 사용자에게 영향을 주지 않는다.
- 구체화된 대상이 변경되더라도 동일한 인터페이스를 제공하면 아무런 문제 없이 상호작용이 가능하다.

객체의 인터페이스는 객체가 수신할 수 있는 메시지의 목록으로 구성되기 때문에, 객체가 어떤 메시지를 수신하는지에 따라서 달라진다.
여기서 말하는 인터페이스는 외부에서 접근 가능한 것과, 내부에서만 접근 가능한 것으로 나누어지며,

이 둘의 차이는 메시지를 보낸 주체가 다른 객체인지, 객체 자기 자신인지에 따라서 달라진다.

 

🌱 객체의 책임은 자율적이다. 스스로가 결졍해야 한다.
객체는 메시지를 통해 서로 소통하며, 메서드를 통해 메시지를 어떻게 수행할지 결정한다.
객체는 인터페이스를 통해 이러한 메시지를 받을 수 있다.

 

---

✔️ 인터페이스와 구현의 분리

인터페이스의 3가지 원칙은 다음과 같다.
- 인터페이스는 추상적이어야 한다.
- 외부에서 사용할 필요가 없다면 최대한 노출하지 말아야 한다.
- 객체의 내부와 외부를 구현해야 한다.

여기서 말하는 객체의 내부가 무엇일까?
이는, 객체를 구성하지만, 외부에 공개된 인터페이스 (=공용 인터페이스)에 포함되지 않는 모든 것을 의미한다. 이를 곧 ‘구현’이라고 한다.
쉽게 말하면, 캡슐화를 통해 객체의 인터페이스를 제공하여, 구현체를 숨기라는 의미이다.

구체적인 것에 의존하지 않게 되면 변경에 더 유연하게 대응이 가능하며, 내부에서 무엇을 변경하든 외부에는 영향이 끼치치 않기 때문에 우리는 변화하는 객체 세상 속에서 더 좋은 설계를 진행할 수 있게 된다.

 

---

✔️ 객체의 자율성은 왜 이렇게 중요할까?

객체의 책임이 자율적일수록 협력 관계는 이해하기 쉬워지고, 유연하게 변경할 수 있게 되며, 이는 협력에 대한 전체 품질을 결정한다.

객체에게 구체적인 것을 지시하는 순간, 해당 협력 관계도 곧 복잡해진다.

 

앞서 예시를 들었던 알바냥이 셰프냥에게 커피를 만드는 순서까지 제어했던 것처럼, 불필요한 책임까지 안게 되는 것이다. 

또한, 셰프냥이 커피 만드는 순서를 변경하더라도, 알바냥에게 아메리카노 10잔을 만드는 사실은 변함이 없기 때문에 외부에 불필요하게 영향을 끼치지 않게 된다. 내부에서 무엇을 하든 협력 관계는 그대로 유지된다는 것이다.

만약 셰프냥이 휴가를 갔다면?

아메리카노 10잔을 만드는 주체가 셰프냥이 아니라 다른 주체여도 된다.

자율적인 책임으로 인해서, 해당 행위를 수행할 수 있기만 하면 되기 때문이다.

또한, 객체의 책임이 자율적이면 객체의 존재 이유도 명확하게 표현될 수 있다. 
자율적으로 수행하게 되면, 이는 곧 객체의 목적을 달성하는데 집중을 하게 되고, 곧 객체 자체가 목적을 달성하기 위해, 강하게 연관된 책임으로만 구성이 될 수 있다. (= 객체의 응집도가 높아진다!)

 

말이 길었지만, 결과적으로 객체의 책임이 자율적이게 되면 우리는 다음과 같은 이점들을 얻게 된다.

- 응집도가 올라간다.

- 결합도가 낮아진다.

- 캡슐화가 잘 이루어지게 된다.

- 인터페이스와 구현이 명확하게 분리된다.

- 유연성과 재사용성이 향상된다.