이번주에, MVVM을 차근차근 학습하며 구현했다.
감사하게도 내게는 아주 좋은 예제 2개가 있다.
이전에 실력 좋은 페어분들과 미션을 진행했었고, 그분들과 함께 했던 코드를 하나 하나 뜯어보며 학습을 진행하였다.
코드를 보던 중, 내 머리로는 도무지 이해가 안가는 Protocol 을 마주하게 되었다.
이미 추상화가 되어있는 Protocol 을 한번 더 Protocol 로 쪼갠것이다.
함께했던 페어께 질문했고, 답은 명쾌했다.
- 내가 그동안
Protocol에 대해, 제대로 알고있지 않았던 것.
안다는 것 과 제대로 아는 것 은 분명 다르다.
페어는 질문에 대답하는 나를 보고, 텍스트 북을 읽는것 같다고 하셨다.
망치로 맞은 기분과 함께, 부끄러움이 밀려왔다.
그래도 마냥 부끄러워 하기보단, 모르는 걸 알게됐다는 사실에 감사하기로 했다.
페어의 조언에 따라 책 객체지향의 사실과 오해 를 읽었고, 그제야 비로소 모든게 이해가 되었다.
서론이 길었다.
프로토콜은 왜 사용하는가?
책 객체지향의 사실과 오해 에서는, 객체지향 시스템의 목적이
사용자의 요구를 만족시키는 기능 + 이해하기 쉽고 단순한, 또 유연한 상호 작용을 제공하는 객체들의 공동체 구축 이라고 설명하고 있다.
말이 어려운데 단순하게 접근해보자.
나는 객체들의 공동체 에 집중했다.
공동체 안에는 각자의 역할 과 책임 이 존재한다.
객체지향 안에도 역시, 역할 과 책임 이 존재한다.
예를 들면, 나는 집에서 부모님의 문화생활 을 책임지고 있다.
부모님이 문화생활을 하고싶다. 는 메세지를 보내면, 나는 그에 대한 응답을 해야할 의무가 있다.
근데, 내가 바쁠때면 오빠에게 요청을 하시기도 한다.
즉, 부모님은 내가 필요한게 아니다.
본인들의 요청이 담긴 메세지에 응답해줄 책임자 가 필요한 것이다.
이러한 이유로, 역할 을 딸 과 아들 이라는 객체로 만드는 것이 아니라
문화생활 예약자 라는 프로토콜로 추상화 해놓으면, 요청이 들어올 때 해당 역할을 누구든 손 쉽게 대처할 수 있게 된다.
이 말은 즉, 다양한 문맥에서 동일한 구조의 협력을 용이하게 재사용할 수 있다는 것 이다.
✅ 그럼 이미 한번 추상화 한 Protocol 을 또 쪼개는 이유는?
디버깅을 해야하는 상황에, 어디서 누가 어떻게 잘못된 것인지 빠르고 용이하게 파악하기 위함이다.
쉽게 말해, 책임과 역할을 나눠 각자의 역할만 수행 (최소한의 책임만 맡음) 하여, 문제가 생긴 부분을 쉽게 찾도록 하는 것이다.
위처럼 프로토콜은 노출 가능한 책임만 명시 되어있을 뿐, 그 일을 어떻게 처리하는지는 해당 책임을 맡는 객체가 구현한다.
때문에 책임 소재가 명확해지고, 구현하기 위해 사용되는 변수나 메서드들은 캡슐화되어 외부에 노출되지 않게 된다.
이렇게 책임과 역할을 생각하다보니, 네이밍이 어려운 이유를 알게 되었다.
객체든, 프로토콜이든, 메서드든 어떤 역할과 책임을 맡고 있는지 이름에서 드러나기 때문이다.
틀린 내용을 알려주시면 감사하겠습니다!😊
