Boxed Protocol Type

Protocol

• 인터페이스

  • 외부와 상호작용하는 방식을 정의

    

    위의 상황에서 인터페이스의 의미를 알 수 있다
    'method1'만 사용하게 하고 내부적으로 사용하는 method2는 숨김 → 추상화
    

• 코드에서 프로토토콜 타입을 사용하는 2가지 케이스

  1. Generic - where 절 : 타입 제약을 사용하는 경우 제네릭 함수, 서브 스크립트, 타입과 연관된 타입에 대한 요구사항을 정의할 수 있다

     예시)
     

  2. 변수, 상수, 파라미터 반환타입에서 사용 : 프로토콜을 type으로 사용 → Boxed Protocol Type

     예시)
     

Boxed Protocol Type

• Existential Type(실존 타입) : 프로토콜을 타입처럼 사용하는 경우

  • 컴파일 타임에 정확한 타입을 모르기 때문에 런타임에 타입이 결정됨(약간의 성능 오버헤드 발생)

• 'any' : 변수, 상수, 파라미터 반환타입으로 프로토콜을 사용할 때 앞에 any를 붙이는 것을 권장(제안)

• 컴파일 타임에 실제 타입을 알 수 없다.

  • 컴파일 타임에는 프로토콜 타입(Existential Type)으로 취급되고 런타임에 실제 타입(Concrete Type) 취급되는데, 이 처리를 위해 성능 비용이 추가된다.

	- 컴파일 타임 : 작성된 코드를 프로그램(앱)으로 컴파일 하는 시점. 문법/타입 체크, 코드 최적화 등
	- 런타임 : 앱 실행 시점. 코드 실행, 실시간 에러(네트워크 에러 등)

• 인터페이스 용도로 활용

  • 세부 구현을 숨김(추상화, 캡슐화 등)
  • 테스트 가능한 코드로 만든다 ⬇️

  예시)

  위의 예시처럼 기존 코드 대신 프로토콜을 사용해서 테스트용 TestCarrier을 간단하게 만들어 사용할 수 있다

---

💡 Concrete Type VS Existential Type (구체 타입 vs 실존 타입)

• Existential Type(실존 타입) : 프로토콜을 타입처럼 사용하는 경우
  • 컴파일 타임에 정확한 타입을 모르기 때문에 런타임에 타입이 결정됨(약간의 성능 오버헤드 발생)
• Concrete Type : 정확한 타입이 결정된 값
  • 컴파일 타임에 타입이 확정되어 최적화가 가능(성능👍🏻)

- 사용 시기 -

상황	Concrete Type 사용	Existential Type 사용
성능이 중요한 경우	✅ 최적화 가능	❌ 런타임 비용 발생
특정 타입을 다룰 때	✅ struct & class 타입 그대로 사용	❌ 불필요한 타입 추상화
유연성이 중요한 경우	❌ 특정 타입만 사용 가능	✅ 여러 타입을 받을 때 유용
프로토콜을 통한 추상화	❌ 특정 타입에 의존	✅ 다양한 타입을 다룰 때