[WWDC 15] - Protocol Oriented Programming(POP) {2편 - OOP를 POP로 변경해보기}

📂 프로토콜 중심 프로그래밍(Protocol-Oriented-Programming in 408 Session WWDC 15)

🎯 프로토콜 중심 프로그래밍(이하 POP) {2편 - Start with Protocol}

• 1편 - 왜 OOP로는 부족한가?

🔨 문제가 있는 상속 관계를 프로토콜을 활용하여 변경해보기

• 우선 1편에서 언급했던 문제 상황을 다시 한번 살펴보겠습니다.

  

  
  

  문제가 되었던 Ordered를 클래스가 아닌 프로토콜로 변경해보겠습니다.

  

  
  

  프로토콜로 변한다면 XCode는 에러메세지를 띄웁니다. 프로토콜이기 때문에 메소드를 직접 구현하는 것은 안된다고 말이죠. 여기서 Dave가 한 말을 인용해보겠습니다.

  Okay, first, we need a protocol, and right away Swift complains that we can't put a method body here, which is actually pretty good because it means that we're going to trade that dynamic runtime check for a static check, right, that precedes as implemented.

  
  

  해석해보면 이렇게 직접 구현을 제거하므로써 dynamic runtime check를 static check로 바꿀 수 있기 때문에 좋다고 이야기하네요. 그럼 여기서 말하는 dynamic runtime check와 static check는 무엇일까요?

  
  

  🧐 Static test vs Dynamic test

  • Static test: 정적 테스트로 작성한 코드를 직접 검토하여 오류를 유발할 가능성이 있는 코드를 사전에 검출하는 것입니다. 자료형 검사를 컴파일 시간에 수행합니다(빌드 이전에 수행합니다).
  • Dynamic test: 프로그램의 실제 동작을 확인함으로써 원하는 동작을 정상적으로 수행하는지 검토합니다. 자료형 검사를 실행 시간에 수행합니다(빌드 이후 수행합니다).

  
  이 기준으로 Dave의 말을 다시 해석해보면 "메소드가 모두 구현되어 있어 실행시 체크를 해보는게 아니라 필요한 메소드를 명세만 해놓음으로서 정적 체크로 변경한다"로 이해할 수 있을 것 같습니다. 물론 이게 왜 "pretty good"한 trade인지는 조금 더 생각해 볼 필요가 있는 것 같습니다.

  
  

  계속해서 기존 코드를 고쳐나가보겠습니다.

  

  
  

  프로토콜로 변경하므로써 더이상 override의 개념이 아니므로 func precedes는 override가 아니게되고, 클래스였던 Number도 상속 관계가 없어졌기 때문에 class이어야할 당위성이 사라져 struct로 구현했습니다. 이것도 이미 동작하는 코드이고, 충분히 많은 발전이 있었기 때문에 조금 더 나은 코드라고 할 수 있지만 여기서 한걸음 더 나아갈 수 있습니다.

  
  

  

  
  

  Number 타입에 구현되어있는 precedes 메소드의 파라미터 타입을 Number로 바꾸면 당연히 에러가 발생합니다. 프로토콜 Ordered에 명세된 것과 다른 메소드가 구현되었기 때문입니다. 여기서 프로토콜의 precedes 메소드의 other의 파라미터 타입을 Number로 바꾸면 될까요? 물론 당장 동작하는데는 문제가 없을 수 있습니다.

  하지만, 애초에 이러한 프로토콜이 설계된 목적에는 Number가 아닌 다른 타입도 이 프로토콜을 따르게 하는 것도 있을텐데 이렇게 구현이 되면 어떤 타입이든 Number를 타입으로 받아야하는 문제가 발생하죠. 그래서 다음과 같이 수정합니다.

  
  

  

  
  

  Dave는 프로토콜 안에 정의된 Self를 "자기 자신을 채택할 타입을 위한 Placeholder"라고 설명합니다. 굉장히 좋은 표현 같네요!

  그럼 이제 이 구조를 사용할 Binary Search 로직을 볼까요?

  
  

  

  
  

  앞선 변경점 때문에 위와 같은 문제가 발생합니다. Dave의 말에 따르면, 현재 heterogeneous array이기 때문이 이것을 XCode가 homogeneous array로 변경하도록 강요한다는 것입니다. 용어를 생각해보면 heterogeneous는 서로 다른 것을 의미하고, homogeneous는 서로 같은 것을 의미하는데 배열 내부의 타입이 모두 같은 경우 homogeneous array, 다른 경우 heterogenous array라고 할 수 있습니다.

  즉, Ordered는 프로토콜이므로 Ordered를 채택하는 다양한 타입이 존재할 수 있고, 저 배열은 더이상 homogeneous하지 않기 때문에 변경이 필요하다는 것이죠.

  변경 한 후 코드는 아래와 같습니다.

  
  

  

  
  

  제네릭을 사용해서 Ordered를 채택하는 타입 T를 고정하고, 그 타입에 대해 할당해주었으니 이제 [T]는 homogeneous 합니다.

  Self Requirement를 사용하는 것과 사용하지 않는 것의 차이를 표로 정리하면 다음과 같습니다.

  
  

  

  
  

  heterogeneous와 homogeneous의 설명은 위에서 했으니 넘어가고, Self를 사용하지 않으면 서로 다른 타입의 모델들 간에 상호 작용이 가능해야합니다. 어떤 로직이 구현될 때 상호간에 'interaction'이 가능한 관계인지를 정의할 필요가 있는데 다른 타입일 경우 일일이 그 상황들을 알아야 한다는 것이죠.

  다음으로는 Dynamic/Static dispatch인데 우선 이 차이를 명확하게 이해할 필요가 있습니다.

  Dispatch: 프로그램이 어떤 메소드를 호출할 것인가를 결정하여 그것을 실행하는 과정

  Static Dispatch(정적 디스패치): 런타임이 아닌 컴파일시 어떤 클래스의 메소드를 호출할 것인지 명확하게 아는 것.

  Dynamic Dispatch(동적 디스패치): 컴파일 시점에서 어떤 메소드를 호출하는지 모름. 추상 타입의 메소드를 호출하는 것만 알고 있으며 런타임 시점에 할당된 객체의 타입을 보고 메소드를 실행.

  
  

  제가 이해하기로는 [Ordered]의 경우 Ordered에 명시된 메소들은 같은 이름이지만 각각 다른 형식으로 이 프로토콜을 채택하는 타입에 구현되어있을 것입니다. 이것을 Self로 처리하면 통일되어있는 단일화 된 그 객체에서 처리할 수 있으므로 Static한 Dispatch가 가능하다고 할 수 있지만 heterogenous하다면 어떤 메소드가 실행되어야할지 런타임시 까지 알 수 없으므로 Dynamic하다고 표현한 것 같습니다.

  Dave의 표현을 직접 살펴보겠습니다.

  We trade dynamic polymorphism for static polymorphism, but, in return for that extra type information we're giving the compiler, it's more optimizable.

  dynamic이 static한 다형성을 가지므로해서 타입에대한 추가 정보를 얻을 수 있고, 컴파일러에게 더 많은 정보를 줌으로써 더 최적화된 구조를 가질 수 있다는 의미로 해석됩니다.

  
  

📝 Document and Display model을 OOP와 POP로 구현해보기

• Crusty는 여기까지 설명했음에도 불구하고.. 아직 프로토콜을 못 믿습니다. 클래스의 역할을 프로토콜이 완전히 대체할 수 있을까에 대한 의구심이 남아있나봐요. 그래서 Dave는 예시를 통해 Crusty를 설득하는 셀프 연기를 보여줍니다. Document and Display 모델을 통해 프로토콜의 강력함을 보여주려고 합니다.

  
  

  

  
  

  위는 Crutsy가 작성한 예시입니다. Drawing에 관련된 것인데 1편에 언급한 것처럼 Crusty는 GUI를 싫어합니다. 그래서 단순히 프린팅하는 방식으로 구현합니다.

  우선 프로토콜을 생성해서 그림에 필요한 도구들을 생성해줍니다.

  

  

  

  
  

  그리고 이것을 기반으로 그림을 그려봅니다!

  
  

  

  
  

  짜잔! Crusty가 그림이 완성되었다고 말합니다. 하지만 Dave나 제 눈에는 그림으로 보이지 않습니다. 아마 대부분의 사람들에게 그렇겠죠. Dave는 투덜대면서 변경을 요구합니다.

  
  

  3편에서 이어서 진행하겠습니다!

  
  

  Ref: https://developer.apple.com/videos/play/wwdc2015/408/