---
# System prepended metadata

title: Day12-학습정리
tags: [2020 Boostcamp]

---

###### tags: `2020 Boostcamp`
# Day12-학습정리

- ### 스스로 확인할 사항

  - **비동기 처리를 위해서 GCD를 도입할 때 가장 난해하거나 어려운 점은 무엇인가?**
    - 실행시간을 제어할 수 있지만 각 작업간의 시간간격을 알 수 없음
    - 다음 작업이 언제 시작될 지, 특정 시점에 몇개의 작업이 실행중인지 알 수 없음
  - **GCD를 도입한다고 해서 메인 스레드 외에 특정한 스레드를 지정할 수 없다. 지정하려면 어떤 방식을 써야할까?**
    - Thread를 구현하는 방식을 사용
      - `Cocoa Threads`
        * NSThread 클래스를 통하여 구현
        * 'performSelectorInBackground' 메소드를 사용하여 새로운 thread에 실행 로직 부여
      - `POSIX Threads`
        - Thread를 생성하기 위한 C기반 인터페이스
  - **Publisher가 class가 아니라 struct나 enum 타입도 가능한가? 어떤 부분을 수정해야 하는가? 안된다면 어떤 제약사항 때문에 안되는가?**
    - Publisher는 Reference를 가져야 참조 가능
    - struct와 enum은 value type으로 Publisher를 value type으로 설계하면 문제가 발생
    - 따라서 `&`키워드를 통해 reference를 넘기고 받는 식으로 설계해야 함

  ### 다같이 확인할 사항

  - **서로의 구현한 내용이 파운데이션 NotificationCenter와 차이점을 비교하고 토론한다.**

    - Notification 구조체는 Hashble, CustomReflectable, Equatable, ReferenceConvertible의 프로토콜을 따른다
    - NotificationQueue라는 버퍼를 가진다

  - **GCD DispatchQueue 이외에 Timer, Event Source 등 다른 요소는 어떤 경우에 활용할 수 있는지 함께 조사하고 토론한다.**

    - `Timer`

      - 특정 시간이 지난 후에 이벤트를 발생시킬 때
      - 반복적인 주기로 특정 작업을 수행하는 프로그램 작성 시
      - RunLoop에서 Timer Source에 해당

      ```swift
      /// Type method
      class func scheduledTimer(timeInterval ti: TimeInterval, 
                         target aTarget: Any, 
                       selector aSelector: Selector, 
                       userInfo: Any?, 
                        repeats yesOrNo: Bool) -> Timer
      
      /// Timer 객체 생성 후 수동으로 RunLoop에 추가
      init(timeInterval ti: TimeInterval, 
           target aTarget: Any, 
           selector aSelector: Selector,
           userInfo: Any?, 
           repeats yesOrNo: Bool)
      
      RunLoop.current.add(_ timer: Timer, forMode mode: RunLoop.Mode)
      ```

    - `Event Source`

  - **Observer 패턴과 Publisher-Subscriber 패턴을 구분해보고 차이점과 공통점을 토론한다.**

    - Observer패턴은 Observer와 Subject가 서로를 인지하지만 Pub-Sub패턴의 경우 서로를 전혀 몰라도 상관없음

      * Observer패턴의 경우 Subject에 Observer를 등록하고 Subject가 직접 Observer에 직접 알려주어야 함

      * Pub-Sub패턴의 경우 Publisher가 Subscriber의 위치나 존재를 알 필요없이 Message Queue와 같은 Broker역활을 하는 중간지점에 메시지를 던져 놓기만 하면 됨 
      * 반대로 Subscriber 역시 Publisher의 위치나 존재를 알 필요없이 Broker에 할당된 작업만 모니터링하다 할당 받아 작업하면 되기 때문에 Publisher와 Subscriber가 서로 알 필요가 없음

    - Observer패턴에 비해 Pub-Sub패턴이 더 결합도가 낮음

      * Publisher와 Subscriber가 서로의 존재를 알 필요가 없기 때문에 당연히 소스코드 역시 겹치거나 의존할 일이 없음

    - Observer패턴은 대부분 동기(synchronous) 방식으로 동작하나 Pub-Sub패턴은 대부분 비동기(asynchronous) 방식으로 동작함

    - Observer패턴은 단일 도메인 하에서 구현되어야 하나 Pub-Sub패턴은 크로스 도메인 상황에서도 구현 가능