델리게이트 패턴에서 제네릭으로 – Swift

(제목이 스포일러이긴한데…) 간단한 클래스를 하나 작성해보자. 0으로 시작하는 값에서 메소드를 하나를 호출하면 그 값을 1씩 증가시켜나가는 것이다.

class Counter {
  var value: Int = 0
  func increase() {
    value += 1
    print("value: \(value)")
  }
}

현실적으로는 별 쓸 데 없는 이 클래스를 사용하려 할 때, 값이 변할 때 수행하는 동작을 입맛에 맞게 커스터마이징하고 싶은 경우가 있을 수 있다. 물론 increase() 메소드를 그 때 그 때마다 변경하면 되지만, 소스를 직접 수정할 수 없는 서드파티가 이 클래스를 사용한다면, 델리게이트를 만들어서 값이 변하는 이벤트의 처리를 맡길 수 있다. 예를 들어 변경된 새 값이 짝수인 경우에만 출력한다던가, 화면 출력이 아닌 파일로 저장한다던가 혹은 네트워크를 통해 서버에 값을 업로드하려고 할 수도 있을텐데, 델리게이트가 해당 동작을 수행하도록 한다면 우리는 델리게이트가 지정된 메소드를 호출하게끔만 해주면 될 일이다.

델리게이트를 구현하기 위해서는 보통 델리게이트에 필요한 프로토콜을 정의하고, 해당 프로토콜을 따르는 델리게이트 클래스를 작성해야 한다. 예를 들어 이런 식이다.

class Counter {
  weak var delegate: CounterDelegate?
  func increase() {
    value += 1
    delegate?.valueDidChange(value)
  }
}

protocol CounterDelegate {
  func valueDidChange(_ value: Int)
}

class Foo: CunterDelegate {
  func valueDidChange(_ value: Int) {
    if value % 2 == 0 { print("value: \(value)") }
  }
}

물론, 위 코드는 정상적으로 컴파일 될 수 없다. Swift에서 weak로 정의되는 프로퍼티는 반드시 class 타입이어야 한다. 따라서 프로토콜 CounterDelegateclass를 상속받아 정의되어야 할 것이다.

protocol CounterDelegate: class { ...

타입 메소드로 변경하기

많은 경우 델리게이트 패턴에서, 델리게이트 그 자체는 특정한 상태값을 유지할 필요가 없는 경우가 많다. 대신 델리게이트는 델리게이트 메소드를 제공하는 호스트의 역할을 담당하기 때문에 인스턴스로 만들어지는 경우가 많다. 만약, 델리게이트가 특정한 상태값을 유지하고 있을 필요가 없다면 델리게이트 메소드가 반드시 인스턴스 메소드여야 할 이유는 없을 것이다. 그렇다면 다음과 같이 델리게이트 구현을 바꾸는 것은 어떨까?

protocol CounterDelegate {
  static func valueDidChange(_ value: Int)
}

이 프로토콜은 클래스가 아닌 struct나 enum 타입들도 따를 수 있게 된다. 특히 인스턴스를 만들 필요가 없으니 enum 으로 다음과 같이 만들어볼 수 있겠다.

enum Foo: CounterDelegate {
  static func valueDidChange(_ value: Int) {
    if value % 2 == 0 {
      print("value: \(value)")
    }
  }
}

그렇다면 Counter는 어떻게 수정되어야 할까? delegate 프로퍼티는 특정한 타입의 객체가 아닌, 타입 그 자체를 가리켜야 하고, 따라서 delegate의 타입은 CounterDelegate가 아닌 CounterDelegate.Type을 사용하게 된다.

class Counter {
  var delegate: CounterDelegate.Type?
  var value: Int = 0 
  func increase() {
    value += 1
    delegate?.valueDidChange(value)
  }
}

다시 제네릭으로 옮겨가기

그렇게 따지고보면 delegate는 Counter 클래스의 연관 타입(associated type)으로 볼 수 있다. 그렇다면 굳이 프로퍼티로 정의할 필요 없이, Counter 자체가 제네릭 타입이면 되는 것이다. 즉 이를 테면 Delegate라는 연관 타입을 가지는데, 이 연관 타입은 CounterDelegate 프로토콜을 따라야 한다. 이는 클래스 선언 부분에서 제네릭에 대한 where 절을 통해서  델리게이트 타입이 해당 프로토콜을 따르는 것을 명시하면 된다.

class Counter<Delegate> where Delegate: CounterDelegate {
  var value: Int = 0 
  func increase() {
    value += 1
    Delegate.valueDidChange(value)
  }
}

이렇게 되면 델리게이트에 대한 프로토콜과, 그 프로토콜을 따르는 타입만이 존재한다. 델리게이트의 인스턴스는 필요하지 않으며, 오직 Counter를 생성할 때 연관되는 델리게이트의 타입만을 명시하면 된다. 이렇게 의존성을 주입하는 코드가 간결해지고, 다음과 같이 사용될 수 있다.

do {
  let c = Counter<Foo>()
  for _ in (0...20) {
    c.increase()
  }
}

한계

여기서 보인 예시는 델리게이트를 다른 객체 인스턴스가 아닌 타입 자체로 옮기면서 연관 타입이 위임의 대상이 되는 것을 통해서 제네릭으로 델리게이트 구현을 바꿀 수 있다는 개념을 보인 것이다. 즉 “이런게 된다”는 것이지 이것이 기존의 방법보다 반드시 좋다고는 볼 수 없다. 특히 현재 Swift 및 Cocoa의 기능에서는 몇 가지 한계가 있는데 우선 델리게이트 관계는 통상 인터페이스 빌더에서 많이 연결된다. 인터페이스 빌더에서 연결된다는 의미는 결국 Objective-C 런타임을 통해서 구성된다는 것이고, Objective-C에서는 제네릭을 지원하지 않기 때문에 IB에서는 제네릭을 통한 위임을 사용할 수 없다. 또한 현재의 Swift 타입 시스템은 concrete type만을 타입으로 인식한다. 즉 Counter<Foo>는 어떤 타입으로 특정됨에 비해서 타입 파라미터가 생략된 Counter는 아직까지는 그 자체로는 “타입을 만들기 위한 틀”, 즉 메타 타입이며 이는 타입으로 취급되지 않는다. (이 부분은 향후 Swift의 제네릭 시스템에서 higher-kinded 타입을 지원하게 되면 해결될 수 있을 것이다.) 따라서 실제로는 그럴 필요가 전혀 없겠지만, 델리게이트 타입이 Counter 스스로가 되도록 정의할 수 있는 직접적인 방법은 없다.

 

제네릭타입을 활용한 델리게이트 패턴

델리게이트는 보통 특정한 이벤트처리를 위해서 코코아에서 가장 널리 사용되는 패턴 중 하나이다.  델리게이트를 구현하기 위해서는 보통 다음의 준비를 가져야 한다.

  1. 델리게이트 메소드를 호출하려는 객체(호스트라고 하자)는 델리게이트의 클래스가 무엇인지 알 필요가 없고, 사실 알 수도 없다. 따라서 델리게이트 메소드들은 별도의 프로토콜에 정의한다.
  2. 호스트는 프로토콜을 따르는 익명의 타입의 델리게이트 프로퍼티를 갖는다. 이 때 델리게이트는 존재할 수도, 존재하지 않을수도 있으며 메모리 관리상의 안전을 위해 약한 참조를 사용한다.

따라서 Swift에서는 이 내용을 코드로 표현하면 아래와 같이 나타낼 수 있다. 이 때 몇 가지 디테일에 주목해야 한다.

protocol CustomViewDelegate: class // # 1
{
  func customViewDidFinishEditing(_ view: UIVIew)
}

class MYCustomView: UIView {
  weak var delegate: CustomViewDelegate? ## 2
  
  @IBAction func finishEditing(_ sender: Any?) {
    delegate?.customViewDidFinishEditing(self)
    ...
  }
}
  1. 보통 델리게이트를 weak var 에 옵셔널 타입을 써서 선언하는데, 이렇게하면 델리게이트가 될 수 있는 객체의 타입은 반드시 클래스여야 한다. 값 시멘틱의 타입 객체는 weak 가 될 수 없다.
  2. 따라서 프로토콜 CustomViewDelegate는 오직 클래스 타입에서만 따를 수 있기 때문에 프로토콜 선언 시에 class를 붙여주어야 한다.

그리고 실제로 델리게이트를 사용하기 위해서는 델리게이트 객체를 생성해서 의존성을 주입해주어야 하는 절차를 반드시 거쳐야 한다. 코코아의 많은 내장 클래스에서는 델리게이트가 아웃렛으로 정의되어 있기 때문에 보통 우리는 이 과정을 인터페이스 빌더 내에서 연결하여 수행하게 된다.

조금 다른 스타일로 델리게이트 패턴 구현하기

Swift에서 이러한 델리게이트를 조금 다른 방식으로 구현할 수 있는 방법에 대해서 살펴보자. 일단 기존 방식의 문제는 “델리게이트가 되는 객체 인스턴스”가 필요하다는 점이 그 원인이 된다. 많은 경우에 델리게이트는 델리게이트 메소드의 구현을 제공하는 용도로 제작되며, 델리게이트 자체가 특정한 상태값을 저장하고 있는 경우는 많지 않다. (보통 호스트에 대한 참조를 필요로 하는 경우가 있지만, 이런 경우에는 델리게이트 메소드에서 호스트가 자신을 인자로 넘기는 방식으로 참조한다.) 따라서 프로토콜에서 델리게이트 메소드를 타입 메소드로 지정해버리는 것이다.

protocol CustomViewDelegate {
  static func customViewDidFinishEditing(_ view: CustomView)
}

이렇게 델리게이트 프로토콜을 정의했다. 이제 호스트에서 델리게이트는 인스턴스가 아니라 타입 그 자체가 될 것이기 때문에 다음과 같이 정의를 수정할 수 있다.  그리고 이 타입에 대한 의존성을 주입하기 위해서는 별도의 이니셜라이저를 아래와 같이 정의해야 한다.

class CustomView: UIView {
  var delegate: CustomViewDelegate.Type

  init(frame: CGRect, delegate: CustomViewDelegate.Type) {
    super.init(frame:frame)
    self.delegate = delegate
    ...
  }
  ...
}

뭔가 일이 더 꼬여버리는 느낌이다. 그런데 델리게이트가 타입 그 자체라고 하면, 이런식으로 프로퍼티로 설정하기 보다는 연관 타입으로 대체하는 것도 가능하지 않을까?

class CustomView<S: CustomViewDelegate>{
  typealias Delegate = S
  ...
}

이렇게하면 delegate라는 프로퍼티 없이, Delegate 연관 타입을 사용해서 간단하게 델리게이트 메소드를 호출할 수 있다. 예를 들어 다음과 같은 case를 가지지 않는 enum을 델리게이트 용으로 정의하고…

enum Foo: CustomViewDelegate {
  static func customViewDidFinishEditing(_ sender: CustomView) {
    print(sender.value)
  }
}

CustomView 클래스는 델리게이트 타입에 의존하는 제네릭이 되므로 다음과 같이 사용할 수 있다. 전체적으로 귀찮았던 부분들이 해소되는 것 같다.

let customView = CustomView<Foo>(frame: myRect)
...

한계

물론 프로토콜과 제네릭이 만능은 아니다. 이렇게 제네릭으로 변경한 패턴은 사실 코코아/코코아터치 앱을 사용할 때 적극적으로 사용할 수 없다. 애초에 인터페이스 빌더는 Objective-C 런타임 위에서 돌기 때문에 이렇게 정의한 Swift 클래스와 타입들을 인식하지 못하기 때문이다. 다만, 제네릭을 사용해서 의존성을 활용하는 방법을 이렇게 바꿀수도 있다는 것은 참고삼아 알아두도록 하자.

What Happened to NSMethodSignature?

NSInvocation에 대해 찾아보다가 Swift 공식 블로그에서 찾은 글을 간단히 번역해본다.

https://developer.apple.com/swift/blog/?id=19

What Happened to NSMethodSignature?

코코아 프레임워크를 Swift로 옮기는 것은 우리 스스로가 우리의 API를 새로운 관점에서 볼 수 있는 좋은 기회가 되었습니다. 우리는 Swift의 목표에 맞지 않는다고 생각되는 클래스들을 찾았고, 우리의 우선순위는 주로 안전성에 맞췄습니다. 예를 들어 동적인 메소드 호출(dynamic method invocateion)과 관련된 클래스들은 Swift에 반입되지 않습니다. 이러한 클래스에는 NSInvocationNSMethodSignature가 있지요.

우리는 최근에 이 클래스들이 빠져있음을 발견한 한 개발자로부터 버그 리포팅을 받았습니다. 이 개발자는 Objctive-C에서 메소드 인자들의 타입을 검사하는데 NSMethodSignature를 사용하고 있었고, Swift로 마이그레이션하는 과정에서 이 클래스를 사용할 수 없다는 것을 알았습니다. 실제 그 코드는 인자 타입이 정해지지 않은 HTTP 핸들러릘 받도록 되어 있었습니다. 예를 들면 이런 것들이죠. What Happened to NSMethodSignature? 더보기

[Swift] 연관 타입(Associated Type)

연관타입(Associated Type)

Objective-C의 Associated Object와 비슷한 명칭이라 좀 헷갈릴 수 있는데, 연관타입은 프로토콜 등에서 현재 타입과 관련이 있는 타입을 의미한다.

연관타입은 프로토콜의 일부에 쓰이는 어떤 타입에 대한 플레이스홀더같은 것으로 프로토콜이 실제로 적용되기 전에는 사용되지 않는 타입1을 말한다. 연관타입은 typealias 키워드를 통해 정의한다. 다음 예는 Container라는 프로토콜의 정의이다.

protocol Container {
    typealias ItemType
    mutating func append(item: ItemType)
    var count: Int { get }
    subscript(i:Int) -> ItemType { get }
}

위 프로토콜은 세 가지 특정을 정의하고 있다. [Swift] 연관 타입(Associated Type) 더보기