[Swift] Objective-C

 

@objc는 언제 사용하나요?

@objc 어트리뷰트는 Swift 코드가 Objective-C 기반 API에서 동작할 수 있게 할 때 사용됩니다. 주로 UIKit에서 Target-Action 패턴의 #selector에 사용되는 메서드에 붙혀집니다. 또한, KVC에서 사용되고 dynamic 키워드와 함께 KVO를 활용할 때에도 사용됩니다. 

 

📌 Target-Action 패턴

 

Target-Action 패턴은 Apple의 UI 프레임워크에서 이벤트 기반 프로그래밍에 사용되는 디자인 패턴입니다. 아래 코드와 같이 특정 이벤트가 발생했을 때, 미리 지정된 객체(타겟)의 메소드(액션)를 호출하는 방식으로 작동합니다. 즉, 이벤트의 발생과 그에 대한 반응을 분리하여 관리할 수 있어 코드의 재사용성과 유연성이 향상됩니다.

 

let button = UIButton()

button.addTarget(self, action: #selector(buttonTapped), for: .touchUpInside)

@objc func buttonTapped() {
	print("Action!")
}

 

 

 

📌 Selector

Objective-C는 Message Dispatch 방식을 사용하여 런타임에 호출될 메서드를 찾는데, 이때 호출할 메서드를 식별할 때 사용하는 것이 Selector입니다. UIKit은 Objective-C 기반 프레임워크이다 보니 Objective-C 기반 API들이 존재하여 메서드 호출을 위한 Selector가 Swift에도 필요합니다.

 

Swift 2 시절 Selector

아래 그림과 같이 문자열 기반 Selector(NSStringFromSelector)를 지원하였습니다.

Swift 2 시절 문자열 기반 Selector를 활용하는 코드

Swift 3 이후 Selector

문자열 기반 Selector의 문제점은 문자열이기 때문에 오타일 경우 컴파일 타임에 에러를 잡아주지 못해 런타임 에러가 발생한다는 점입니다. 따라서, #selector() 키워드로 컴파일 시에 오류를 잡을 수 있게 변경되었습니다.

 

 

@objc와 dynamic의 차이점이 무엇인가요?

@objc는 Swift 코드가 Objective-C 런타임에서 인식될 수 있도록 해주는 어트리뷰트입니다. 이 어트리뷰트를 사용하면 Swift 코드의 클래스, 메서드, 속성 등을 Objective-C 코드에서 사용할 수 있습니다. 주로 Selector 같은 Objective-C 런타임 기능(Message Dispatch)을 이용해야 할 때 주로 사용됩니다. 하지만, Objective-C 런타임 기능을 사용하지 않을 때에는 Swift의 Static Dispatch나 Table Dispatch 방식이 적용됩니다.

 

 

dynamic 키워드는 Swift3 까지는 dynamic 키워드만 적어도 자동으로 @objc 어트리뷰트를 포함했으나 Swift4부터 @objc dynamic 같이 명시적으로 작성해야 하는 것으로 변경되었습니다. 해당 키워드는 @objc 어트리뷰트 기능에 더해, Swift 요소가 Objective-C의 Message Dispatch 방식을 사용하도록 강제하는 역할을 합니다. 이에 따라 런타임에 메서드를 교체하는 Method Swizzling이나 KVO에 사용됩니다.

 

📌 Method Swizzling

Method Swizzling이란 런타임에 메서드를 교체하는 것입니다. Swift에서는 런타임에 메서드를 교체할 순 없어 교체가 필요한 상황에 Objectiv-C 런타임 기능을 활용하여 수행할 수 있습니다. 메서드 교체가 필요한 상황에 대한 설명은 아래 링크로 대체하겠습니다.

Swift ) Method Swizzling

 

 

KVC란?

KVC란 Key-Value Coding의 약자로 객체의 프로퍼티에 '. 연산자'를 사용해 직접적으로 접근하는 것이 아니라 프로퍼티명을 문자열 키로 하여 간접적으로 접근하는 매커니즘입니다. Objective-C의 유산으로서 Swift에서 @objc 어트리뷰트를 사용하여 구현 가능합니다.

KVC는 아래와 같이 코드를 작성하는 시점에는 어떤 프로퍼티의 값을 가져오고 싶은지 정하지 않고 프로그램 실행 중에 원하는 프로퍼티의 값을 가져오게 할 수 있는 등 조금 더 동적인 프로그래밍을 가능하게 해줍니다.

 

 

Swift 2 시절 Selector와 마찬가지로 Key가 문자열이므로 오타나 잘못된 키를 사용하면 컴파일 에러가 아닌 런타임 에러가 발생하는 문제점이 존재합니다. 따라서, 컴파일 타임에 안전성 검사를 할 수 있는 Swift식 KVC인 KeyPath가 등장합니다. 자세한 설명은 링크를 참조해주세요.

Key-Value Coding(KVC) / KeyPath in Swift

 

 

KVO란?

KVO란 Key-Value Observing의 약자로 Objective-C 런타임을 활용하여 객체의 특정 프로퍼티의 변화를 다른 객체에게 알릴 수 있는 커뮤니케이션 패턴입니다. NSObject를 상속한 객체의 @objc dynamic 키워드를 붙힌 프로퍼티여야 KVO를 적용할 수 있습니다.

 

사용 예시

new, old 옵션 사용

import Foundation

class Person: NSObject {
    @objc dynamic var name: String
    
    init(name: String) {
        self.name = name
    }
}

var jinyoo = Person(name: "jinyoo")

jinyoo.observe(\.name, options: [.new, .old]) { (object, change) in
    print(object.name)
    print(change.oldValue, change.newValue)
}

jinyoo.name = "Jinyoo"

// "Jinyoo"
// Optional("jinyoo") Optional("Jinyoo")

 

initial 옵션 사용 -> 초기화 과정도 변화로 인지

var jinyoo = Person(name: "jinyoo")

jinyoo.observe(\.name, options: [.new, .old, .initial]) { (object, change) in
    print(object.name)
    print(change.oldValue, change.newValue)
}

jinyoo.name = "Jinyoo"

// jinyoo
// nil Optional("jinyoo")
// Jinyoo
// Optional("jinyoo") Optional("Jinyoo")

 

prior 옵션 -> 변화 이전과 변화 이후 상태에 모두 호출 

var jinyoo = Person(name: "jinyoo")

jinyoo.observe(\.name, options: [.new, .old, .prior]) { (object, change) in
    print(object.name)
    print(change.oldValue, change.newValue)
}

jinyoo.name = "Jinyoo"

//jinyoo
//Optional("jinyoo") nil
//Jinyoo
//Optional("jinyoo") Optional("Jinyoo")

 

💡 KVO, 프로퍼티 옵저버, @Published, NotificationCenter 비교 (옵저빙을 활용한 커뮤니케이션 패턴들의 비교)

KVO
• Objective-C 런타임 사용
• 객체 외부에서 프로퍼티 옵저빙 관련 코드 작성
• 프로퍼티 변경에 대한 처리 코드가 즉시 실행(동기적)
• 초기화에 대한 알림을 받을 수 있는 옵션 존재

 

프로퍼티 옵저버
• 객체 내부에서 프로퍼티 옵저빙 관련 코드 작성
• 프로퍼티 변경에 대한 처리 코드가 즉시 실행(동기적)
• 초기화에 대한 알림은 받지 못함

 

Combine의 @Published 프로퍼티 래퍼
• 객체 외부에서 프로퍼티 옵저빙 관련 코드 작성 가능
• receive(on:) 오퍼레이터 사용 시 즉시 실행되지 않음(비동기적)
• 초기화에 대한 알림이 디폴트 (dropFirst 오퍼레이터 사용 시 초기화에 대한 알림을 무시할 수 있음)

 

📌 receive(on:) 오퍼레이터의 비동기적 실행을 확인해볼 수 있는 코드

import Foundation
import Combine

class A {
    @Published var name: String
    
    init(name: String) { self.name = name }
}

class B {
    var name: String {
        didSet {
            print("B")
        }
    }

    init(name: String) { self.name = name }
}

class Observing {
    var a: A
    var b: B
    var cancellables = Set<AnyCancellable>()

    init(a: A, b: B) {
        self.a = a
        self.b = b
        self.useCombine()
    }
    
    private func useCombine() {
        self.a.$name
            .dropFirst()
            .receive(on: RunLoop.main)
            .sink { new in
                print("A")
            }
            .store(in: &cancellables)
    }
}

var a = A(name: "jinyoo") // @Published 프로퍼티 래퍼 사용 객체
var b = B(name: "jinyoo") // 프로퍼티 옵저버 사용 객체
var obs = Observing(a: a, b: b)

obs.a.name = "Jinyoo"
obs.b.name = "Jinyoo"

// B
// A

 

📌 receive(on:) 오퍼레이터를 사용하지 않는다면?

receive(on:) 메서드를 사용하지 않는 경우, Combine의 @Published 프로퍼티의 변화 감지나 다른 Combine 스트림의 처리 결과는 receive(on:)을 사용하여 지정한 스케줄러에 의존하지 않게 됩니다. 따라서, 어떤 스케줄러에서 실행될지는 기본적으로 발행(publish)하는 쪽의 컨텍스트를 따르게 됩니다. 여기서의 주요 차이점을 간략히 설명하면 다음과 같습니다.

---

디폴트 동작: receive(on:) 없이, Combine의 오퍼레이터들은 upstream에서 받은 작업을 그들이 받은 같은 스레드 또는 실행 컨텍스트에서 처리합니다. 이는 소스 값이 변경되어 발행되는 스레드와 동일한 스레드에서 구독자의 코드가 실행되는 것을 의미할 수 있습니다.

 

즉각적 실행: 특별한 스케줄러를 지정하지 않으므로, 변경 사항 감지 후 해당 변화를 처리하는 클로저는 가능한 빠르게 실행될 수 있습니다. 하지만, 이는 원래의 작업 스레드가 가벼운 작업을 수행하고 있어야 가능한 일입니다.

 

메인 스레드와의 관계: UI를 업데이트하는 작업과 같이 메인 스레드에서 실행되어야 하는 코드일 경우, receive(on:)을 사용하지 않으면 발행(publish)되는 컨텍스트가 메인 스레드가 아닐 때 UI 업데이트 코드가 메인 스레드가 아닌 곳에서 실행될 수 있는 문제가 발생할 수 있습니다. 이 경우, 기대하지 않은 동작이나 앱 크래시로 이어질 수 있는 위험이 있습니다.

 

NotificationCenter
• 다른 것들과 다르게 프로퍼티 변화보다 객체 간 커뮤니케이션에 더 중점을 둔 옵저빙에 가까움
•  따라서, 다른 세 개보다 Delegate 패턴과 비교해서 공부하는 것이 더 효과적

Delegation, Notification, 그리고 KVO