[WWDC 15] - Protocol Oriented Programming(POP) {1편 - 왜 OOP로는 부족한가?}

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

 

🎯 프로토콜 중심 프로그래밍(이하 POP) {1편 - 왜 OOP(Object Oriented Programming)으로는 부족한가?}

 

• 2015년 WWDC의 POP 설명 영상을 통해 POP를 이해해보겠습니다.
• 양이 너무 많은 관계로 여러 편에 나누어 진행하도록 하겠습니다.
• WWDC에서는 Crusty(심슨?)라는 아저씨를 등장시켜 장단점을 주고 받는 형식의 발표를 진행합니다!

 

📂 Classes are Awesome!

 

• POP를 설명하기 위해 기존에 사용하던 OOP의 개념에 활용되었던 Class의 장점을 먼저 설명합니다.
  1. Encapsulation(캡슐화): 관련 데이터와 동작들을 모아둘 수 있습니다.
  2. Access Control(접근제어): 코드 외부와 내부를 구분짓는 벽을 세워 외부에서의 접근에 제한을 둘 수 있습니다. 이를 통해 정보에 대한 불변성을 유지할 수 있습니다.
  3. Abstraction(추상화): 추상화를 통해 우리는 관련시킬 수 있는(relatable) 정보들을 대표하는 클래스를 사용할 수 있습니다. 쉽게 말해 구체화 되어 있는 정보를 추상화함으로써 서로 다른 정보들간의 공통점을 하나의 클래스로 표현할 수 있다고 볼 수 있습니다.
  4. NameSpace: 소프트웨어가 커지면서 발생할 수 있는 충돌을 대비하는데 도움을 주는 이름 공간(Name Space)를 제공합니다.
  5. Name Space: 내부 식별자에 사용될 수 있는 유효 범위를 제공하는 선언적 영역을 의미합니다.
  6. 출처: TCPSchool
  7. Expressive Syntax: Expressive란 이해하기 쉬운 코드를 작성하기 쉽다고 이해할 수 있습니다. 즉, 클래스를 통해 프로퍼티, 메소드 등의 흐름으로 이해하기 쉬운 구문을 작성할 수 있습니다.
  8. Extensibility(확장성): 누군가가 작성해놓은 코드에 언제든지 기능을 추가할 수 있습니다.
• 
• 하지만 Crusty는 위의 모든 것을 struct와 enum을 통해서 할 수 있다고 주장합니다.. 이 말 때문에 발표자(이하 Dave)는이라는 재미있는 표현을 썼네요 ㅎㅎ여기에 Dave는 반격을 위해서 OOP로 이룬 수많은 업적 중에 가장 강력한 한방을 준비합니다. 클래스로만 할 수 있는 상속 같은 것 말이죠.거기에 더해 진짜 장점은 아래의 문장에서 표현합니다.해석해보면 OOP의 진짜 강점이 나오는 것은 슈퍼 클래스를 작성할 때 어떤 작업의 작은 부분을 하위 클래스가 재정의(Override)할 수 있는 Customization point(사용자가 정의한 포인트)로 나누고, 이 부분이 서브클래스의 구현에서 중첩될 때 발생합니다. 이를 통해 어려운 로직도 재사용이 가능해지고 유연성과 다양성을 가질 수 있습니다.
  Dave가 1인 2역을 상당히 잘하시네요.. :)
  너가 말하는 customization을 나는 항상 struct로 하고있어, 그리고 class가 좋은건 인정하는데 그럼 거기에 따른 비용을 얘기해볼까?
  라고 하면서 Class에 대한 불만 3가지를 이야기합니다.
  😡 클래스는 자동화된 공유를 한다:어떤 A가 B에게 괜찮아보이는 정보를 줄 때 B는 그 정보를 받고, '대화가 끝났군'이라고 생각합니다. 원하는 정보를 받았기 때문에 더이상 대화할 이유가 없겠죠. 하지만 갑자기 이상한(?) A가 이 데이터를 보는 것에 지쳐서 데이터를 Pony 데이터로 바꿔버립니다. Pony를 사랑하기 때문에 누가 Pony 데이터를 싫어하겠어? 하고 말이죠. 이 순간에는 사실 아무 문제가 없습니다. 문제는 B가 이 데이터를 보려고 할 때 발생합니다. 필요한 정보를 보려고 봤는데 갑자기 Pony가 들어있으니까 말이죠!여기에 Crusty가 추가로 불만을 토로합니다.
  '너는 코드에 있는 버그를 제거하려고 마구잡이로 모든 것을 복사하기 시작할거야. 근데 너무 많은 복사본을 만들어서 이건 코드가 느려지게 만들거야. 그리고 어느날 너가 dispatch queue로 어떤 작업을 하려고 할 때 쓰레드가 mutable state를 공유하고 있기 때문에 race condition에 빠질 수 있어. 그럼 불변성을 보호하기위해 lock을 추가하기 시작할거야. 그런데 이 lock들이 코드를 느리게 만들고 데드락을 초래할 수도 있지. 그리고 이 복잡한 상황은 한마디 "버그"라고 정의될거야.'
  여기서 나오는 용어들은 CS 관련된 것이 많아 추가적인 정보가 필요하지만 이 글에서는 추가로 다루지 않겠습니다! 혹시 모르는 용어가 있다면 찾아보면 좋을 것 같습니다. 한가지만 설명하자면 mutable state란 생성 후 변할 수 있는 상태를 말합니다. 반대는 불변 상태가 되겠죠? 상수처럼 한번 생성하면 변경할 수 없는 상태입니다.정리하면 결국 변할 수 있는 상태를 많이 공유할 수록 문제를 야기할 수 있는 구조가 되기 쉽다는 것입니다.
  😡 클래스 상속은 너무 참견한다(class inheritance is too intrusive):
  Swift에서 상속은 단일 상속으로 하나의 클래스는 하나의 수퍼클래스만 가질 수 있습니다. 마찬가지로 서브클래스도 하나만 가질 수 있겠죠.또 수퍼클래스에 저장 프로퍼티가 존재할 수 있는데 이렇게되면 서브클래스에는 다음의 제약사항이 발생합니다.그리고 무엇을 어떻게, 언제 오버라이드 할 지 알아야합니다.
  😡 타입 간의 관계가 중요한 프로그램에서 클래스로 구현하는 것은 적합한 방식이 아니다:
  이진탐색처럼 두 요소를 비교에해야하는 등의 대칭 연산에서 이 의미를 조금더 명확히 알 수 있습니다.
  
  
  
  이 상황에서 빈칸에 들어갈 수 있는 것은 무엇이 있을까요?
  
  
  
  이런 에러밖에 없습니다. Ordered 클래스를 상속받는 서브클래스를 구현해 조금 더 의미를 명확히 해보겠습니다.
  
  
  
  Number클래스는 Ordered를 상속 받습니다. 이 때 비교를 위한 precedes를 오버라이드하면 어떨까요? 당연히 작동하지 않습니다. precedes의 파라미터인 other는 숫자가 아닌 임의의 순서로 구성된 Ordered임을 알 수 있습니다. 그래서 other이 값 프로퍼티를 갖는지 알 수 없습니다. 사실 Label이라는 텍스트 프로퍼티를 가진 객체일 수도 있습니다.
  

  class Label : Ordered { var text: String = "" ... }

  
  그래서 이 문제를 해결하기 위해서는 Number라는 타입으로 다운캐스트 할 필요가 있으며 이는 코드로 표현하면 아래와 같습니다.
  

  class Number : Ordered {
    var value: Double = 0
    override func precedes(other: Ordered) -> Bool {
      return value < (other as! Number).value // 다운캐스트
    }
  }

  
  위와 같은 다운 캐스트 구조(as! ASubclass)는 사실 타입들간 관계에서 유실이 발생했다는 뜻입니다. 이런 문제가 발생하는 이유는 클래스를 통해서는 그 자신의 타입과 다른 타입간의 중요한 관계를 표현할 수 없기 때문입니다. 그리고 이런 경우는 보통 클래스들로 추상화를 표현할 때 발생합니다.
  그럼 이런 문제들을 해결하기 위한 추상화 구조는 어떤 것들을 필요로 할까요?
  
  
  
  간략하게 정리하면 클래스 뿐만이 아니라 값 타입도 지원하고, 정적 타입 관계들을 지원하며 Monolithic하지 않아야 합니다. 여기서 Monolithic이라는 말은 하나의 서비스 또는 앱이 하나의 거대한 아키텍처를 가질 때 Monolithic하다고 하는데, 저는 이것의 이해를 위에서 클래스 단일 상속 이야기 때 나온 개념으로 이해하고 있습니다. 단일 상속의 경우 다양한 상속이 불가능하기 때문에 massive 해질 수 있다는 개념인데, 더 나은 추상화에서는 이런 문제가 해결되야한다고 말이죠. 이런 등등의 장점을 모두 만족시키는 것이 프로토콜(Protocol)입니다. 드디어 메인 주제가 나오네요 ㅎㅎ
  뒷부분은 2편에서 이어서 진행하겠습니다!
  Ref: https://developer.apple.com/videos/play/wwdc2015/408/
• 이런 특징들이 왜 Cocoa에서 델리게이트 패턴을 사용하는지에 대한 이유가 될 수 있습니다.
• • 무조건 수퍼클래스의 프로퍼티를 받아들여야한다.
  • 초기화 작업이 버거워진다.
  • 수퍼클래스의 불변성을 침범하면 안된다.
• 이런 상황에서 만약에 모델이 여러가지 추상화를 필요로하면 어떻게 할까요? 이 개념들을 모아서 직렬화 할 수 있을까요? 클래스인 경우는 힘듭니다. 또한 클래스는 단일 상속으로 관련된 정보를 하나의 클래스에 모두 담게되면 클래스가 비대해집니다. 원하는 만큼 추상화가 힘들기 때문이죠.
• 이야기를 이어가면, 여기에서 Cocoa 개발자들의 공감을 이끄는데 아쉽게도 저는 아직 공감이 안됩니다.. 저도 박수를 칠 수 있는 날이 얼른 오면 좋겠네요.
• 이 극단적인 이야기를 풀어서 설명하면 하나의 정보를 보는 관점은 개체마다 다를 수 있는데 이 정보가 공유되므로써 변경이 일어났을 때 다른 대상에게 큰 영향을 줄 수 있다는 것입니다.
• 여기서 설명한 예시를 이해해보겠습니다.
• Crusty(Dave가 연기하는..)가 여기에 대답합니다!
• But the real magic happens when the superclass author breaks out a tiny part of that operation into a separate customization point that the subclass can override, and this customization is overlaid on the inherited implementation. That allows the difficult logic to be reused while enabling open-ended flexibility and specific variations.
• 상속의 경우 복잡한 로직의 구조에서도 메소드가 정의에 맞게 구현이 되어있다면 서브 클래스에서 편하게 가져다가 쓸 수 있으므로 강력한 툴이라고 볼 수 있습니다.
• 이어서 말하면 Swift에서는 이름을 붙일 수 있는 모든 타입이 일급 객체이므로 위의 모든 기능을 구현할 수 있다고 합니다. 한마디로 굳이 클래스여야하나? 라는 말입니다.
• He let all the air out of my balloon