협력하는 코드 (22.09.01 TIL)

사람들의 가장 흔한 실수는 협력이라는 문맥을 고려하지 않은 채, 객체가 가져야 할 상태와 행동부터 고민하기 시작한다는 것이다. 
중요한 것은 개별 객체가 아니라 객체들 사이에 이뤄지는 협력이다.
훌륭한 객체지향 설계자는 객체들 간의 요청과 응답 속에서 창발하는 협력에 초점을 맞춰 애플리케이션을 설계한다.
협력이 자리잡으면 저절로 객체의 행동이 드러나고 뒤이어 적절한 객체의 상태가 결정된다.

'객체지향의 사실과 오해' 라는 책에서 나온 구절이다. 이 구절 뿐만 아니라 사람들이 오해하고 있는 사실이나 실수 관련 예시를 든 것들이 전반적으로 너무 내 이야기를 하고 있는 문장들이라 헐 맞아!! 라고 공감하면서 읽었다. 메가테라에 온 후의 경험은 아니지만 협력과 의존이 다르다는 것을 (물론 개념적인 의미로 다르다는 것은 알고 있다.) 이해하기 전에는 내가 지금 내 코드에 하고 있는 것, 당당하게 고백하자면, 서로 연결되어 있어서 한 곳을 수정하면 그것이 연결된 다른 곳에도 영향을 미치는 것이 협력이라고 생각했던 것 같다. 아니, 사실 협력이라는 관점을 전혀 생각하지 않았다. 잘 뭉쳐 있으니 된거겠지? 하고 뿌듯해 하기까지 했다. 하지만 이것은 협력이 아니라 의존으로 객체지향에서 완전 위배되는 행위였다. 사실 아직은 초보니까 당연히 똥코드가 나올 수 밖에 없지만 직접 이렇게 협력이라는 것을 생각하지 않고 짠 코드를 마주하니 책에서의 내용이 더 공감이 갔다. 서로에게 전달하는 메세지를 고려하지 않고 냅다 클래스를 만들어서 일단 상태 먼저 선언해놓고 고민하던 과거의 내가 있었고 최근에도 그랬다.

이 문제에 대한 해결 방법으로는 메세지를 요청하는 객체가 따로 있고, 그 요청에 대해 응답하는 객체가 따로 있어서 서로 각자가 맡은 단일 기능만 열심히 수행하는 것이다. 서로 맡은 역할이 다르고 요청 및 응답을 하는 이해관계에만 속해 있기 때문에 한 쪽의 코드를 수정해도 다른 쪽에는 전혀 영향을 끼치지 않는다. 한 마디로 유지보수가 쉬워진다! 이렇게 각자가 맡은 역할만 잘 수행하면 된다. 그리고 또 같은 맥락으로 UI 관련 코드가 사용자가 보는 뷰 화면에만 나오는 것이 아니라 데이터를 처리하는 로직에도 관여를 한다면 이것은 다시 생각해 보아야 할 코드이다. 반대로 데이터를 처리 하는 핵심 로직을 짜는데 UI 관련 코드가 같이 있다면 분리해야겠다는 생각이 들어야 한다. 아샬님 강의영상에서 본 비유를 차용해 보자면, 식당에서 음식을 주문할 때 주문표가 어떻게 생겼든 그것은 음식을 준비하는 주방장에게는 아무 상관이 없는 것이다. 주문표는 주방장에게 '음식 준비' 라는 요청을 전달 하기 위한 가시적인 요소일 뿐이고, 그것이 종이 형태이든 스크린 형태이든, 어떻게 달라지든 말든 주방장은 그저 요청이 들어온 해당 음식만 준비하면 된다.