Protocol Oriented Programming.key.zip

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

Protocol-Oriented Programming in Swift - WWDC15 - Videos - Apple Developer

Classes are Awesome!

POP를 설명하기 위해 기존에 사용하던 OOP의 개념에 활용되었던 Class의 장점을 먼저 설명한다.

• Encapsulation(캡슐화) : 관련 데이터와 동작을을 모아둘 수 있다.
• Access Control(접근제어) : 코드 외부와 내부를 구분 짓는 벽을 세워 외부에서의 접근에 제한을 둘 수 있다. 이를 통해 정보에 대한 불변성을 유지할 수 있다.
• Abstraction(추상화) : 추상화를 통해 우리는 관련시킬 수 있는(relatable) 정보들을 대표하는 클래스를 사용할 수 있다. 쉽게 말해 구체화 되어 있는 정보를 추상화함으로써 서로 다른 정보들간의 공통점을 하나의 클래스로 표현할 수 있다고 볼 수 있다.
• NameSpace : 소프트웨어가 커지면서 발생할 수 있는 충돌을 대비하는데 도움을 주는 NameSpace를 제공한다.
• name space : 내부 식별자에 사용될 수 있는 유효 범위를 제공하는데 선언적 영역을 의미한다 (Reference : TCPSchool
• Expressive Syntax : Expressive란 이해하기 쉬운 코드를 작성하기 쉽다고 이해하는 것이다. 즉, 클래스를 통해 프로퍼티, 메서드등의 흐름으로 이해하기 쉬운 구문을 작성할 수 있다.
• Extensibility(확장성) : 누군가가 작성해 놓은 코드에 언제든지 기능을 추가할 수 있다.

• 위의 모든 표현식은 struct & enum을 활용하여서 표현할 수도 있다.

But, OOP의 진짜 강점 슈퍼 클래스

• 슈퍼 클래스를 작성할 때 어떤 작업의 작은 부분을 하위 클래스가 재정의할 수있는 Customization point로 나누고, 이 부분이 서브클래스의 구현에서 중첩될 때 발생한다. 이를 통해 어려운 로직도 재사용이 가능해지고 유연성과 다양성을 가질 수 있다.

Class’s Problem

1. 자동화된 공유를 한다.

   • 예를 들어, 어떤 A가 B에게 괜찮아보이는 정보를 줄 때 B는 그 정보를 받고, “대화가 끝났군”이라고 생각한다. 원하는 정보를 받았기 때문에 더 이상 대화할 이유가 없다. 하지만 갑자기 A가 이 데이터를 보는 것에 지쳐서 데이터를 Pony(?)데이터로 바꿔 버린다?.
   • 참조 타입이라서 같은 값을 공유해서?
   • A가 맘대로 바꾸면 B가 무슨 데이터인지 모를 수 있다.

   문제는 B가 이 데이터를 보려고 할 때 발생한다

   • 필요한 정보를 보려고 봤는데 갑자기 Pony가 들어있으니까!
   • 너는 코드에 있는 버그를 제거하려고 마구잡이로 모든 것을 복사하기 시작할거야. 근데 너무 많은 복사본을 만들어서 코드가 느리게 된다. 그리고 어느날 너가 Dispatch Queue로 어떤 작업을 하려고 할 때 Thread가 mutable state를 공유하고 있기 때문에 Race Condition에 빠질 수 있다. 그럼 불변성을 보호하기 위하 Lock을 추가하기 시작할거다. 그런데 이 Lock들이 코드를 느리게 만들고 데드락을 초래할 수도 있다.?? ——> Bug??
   • 정리하자면 결국 변할 수 있는 상태를 많이 공유할수록 문제를 야기하는 구조가 되기 쉽다.

   mutable state : 생성 후 변할 수 있는 상태 ↔ 불편상태 immutable state