SwiftでObjective-Cの`+initialize`相当の処理を実現する方法🛠️

はじめに (対象読者・この記事でわかること)

この記事は、Objective-Cでの開発経験があり、Swiftへの移行を検討している方、あるいはSwiftにおけるクラスやモジュールの静的初期化のベストプラクティスについて知りたいSwift開発者を対象としています。Objective-Cの+initializeメソッドは、クラスが初めてメッセージを受信する前に一度だけ実行される初期化処理として広く利用されてきましたが、Swiftには直接的に同等の機能が提供されていません。

この記事を読むことで、Objective-Cの+initializeがどのような役割を担っていたか理解し、Swiftでそれに相当する処理を実現するための複数のアプローチ（static let、アプリケーションレベルの初期化など）とそのメリット・デメリットを学ぶことができます。これにより、Swiftプロジェクトで安全かつ効率的な静的初期化処理を実装できるようになります。

前提知識

この記事を読み進める上で、以下の知識があるとスムーズです。 - Objective-Cの基本的な構文とクラスの概念 - Swiftの基本的な構文（クラス、構造体、クロージャ） - GCD (Grand Central Dispatch) の基本的な概念

Objective-Cの+initializeメソッドとは？その役割と注意点

Objective-Cの+initializeメソッドは、特定のクラスが初めてメッセージ（インスタンスメソッドの呼び出しやクラスメソッドの呼び出し）を受け取る直前に、そのクラスに対して一度だけ呼び出される特別なクラスメソッドです。このメソッドは、主にクラス固有の静的データの初期化や、シングルトンの初回セットアップ、Method Swizzlingなどの高度なランタイム操作に利用されてきました。

+initializeの主な特徴と振る舞い

1. 呼び出しタイミング: そのクラスが初めてメッセージを受信する直前。つまり、そのクラスのインスタンスが生成される前や、そのクラスのクラスメソッドが呼び出される前です。
2. 継承と呼び出し順序: +initializeは継承チェーンを考慮して呼び出されます。具体的には、サブクラスが初期化される前に、スーパークラスの+initializeが先に呼び出されます。そして、各クラスに対して一度だけ呼び出されます。例えば、ParentClassとChildClassがある場合、ChildClassが初めて使用されると、まずParentClassの+initializeが呼び出され、次にChildClassの+initializeが呼び出されます。
3. スレッドセーフ: ランタイムによって一度の呼び出しが保証されており、スレッドセーフに実行されます。
4. 用途:
   • クラスの静的プロパティ（static変数）の初期化。
   • 特定のシングルトンインスタンスの初回設定。
   • 特定のクラスに対して一度だけ行われるランタイム操作（例: Method Swizzling）。

+initializeの注意点

• デッドロックの可能性: +initialize内で他のクラスの+initializeを直接的または間接的にトリガーすると、デッドロックが発生する可能性があります。
• 複数回呼び出しの誤解: 各クラスにつき一度しか呼ばれませんが、サブクラスが存在する場合、そのサブクラスの+initializeが呼び出される前にスーパークラスの+initializeが再度（別のコンテキストで）トリガーされることがあるため、+initializeのロジックが意図せず複数回実行されるように見えることがあります。このため、冪等性（何度実行しても同じ結果になること）を考慮した実装が重要でした。
• 実行順序の制御が難しい: 特定のモジュールやクラス群の+initializeの実行順序を細かく制御することは困難でした。

Swiftでは、これらの+initializeの課題とSwiftらしい安全な設計思想を背景に、異なるアプローチが採用されています。

Swiftで+initialize相当の処理を実現する複数のアプローチ

SwiftにはObjective-Cの+initializeに直接対応するメソッドは存在しません。これは、Swiftがより明示的で安全なコードを推奨する設計思想に基づいているためです。しかし、同様の「クラスがロードされた際に一度だけ実行される処理」を実現する方法はいくつか存在します。

1. static letとクロージャによる初期化 (Swiftらしい推奨アプローチ)

Swiftで最も推奨される、かつ一般的に使われる静的初期化の方法は、static let（静的定数）とクロージャの組み合わせです。これは、+initializeの「一度だけ実行される」「スレッドセーフ」という特性を、よりSwiftらしく安全に実現します。

仕組み

static letで宣言されたプロパティは、そのプロパティが初めてアクセスされた時に一度だけ初期化されます。この初期化処理にクロージャを使用することで、任意の複雑な処理を一度だけ実行させることができます。Swiftのランタイムが、この初期化がスレッドセーフに一度だけ行われることを保証します。

Swift

class MyService {
    // サービスが初めて利用されるときに一度だけ初期化される
    static let shared: MyService = {
        print("MyService singleton is being initialized.")
        // ここに初回に必要なセットアップ処理を記述
        // 例: データベースの接続、APIクライアントの設定など
        return MyService()
    }()

    private init() {
        print("MyService instance created.")
        // インスタンス固有の初期化
    }

    func performOperation() {
        print("MyService is performing an operation.")
    }
}

// 別のクラスでMyServiceを利用する例
class Client {
    func useService() {
        print("Client is trying to use MyService.")
        MyService.shared.performOperation() // ここでMyService.sharedが初めてアクセスされ、初期化がトリガーされる
        MyService.shared.performOperation() // 2回目以降は初期化は走らない
    }
}

// 実行
let client = Client()
client.useService()
// 出力:
// Client is trying to use MyService.
// MyService singleton is being initialized.
// MyService instance created.
// MyService is performing an operation.
// MyService is performing an operation.

メリット

• スレッドセーフ: Swiftランタイムがstatic letの初期化をスレッドセーフに保証します。
• 遅延初期化 (Lazy Initialization): そのプロパティが実際に必要とされるまで初期化が実行されません。これにより、不要なリソースの消費を防ぐことができます。
• 明示的で分かりやすい: コードの意図が明確で、いつ何が初期化されるのかが読みやすいです。
• Objective-Cとの互換性: Objective-Cランタイムに依存しないため、純粋なSwiftクラスでも利用できます。

デメリット

• Objective-Cの+initializeのように、クラス全体がロードされた際に「自動的に」実行されるわけではなく、特定のstatic letプロパティがアクセスされた際に実行されます。クラス全体のロード時に何かをしたい場合は、別の考慮が必要です。
• 継承チェーンを自動的に考慮しないため、親クラスと子クラスでそれぞれ独立してstatic letの初期化を行う必要があります。

2. アプリケーションライフサイクルイベントでの初期化

アプリケーション全体の初期化や、特定のモジュールが利用可能になった際に一度だけ実行したい処理は、アプリケーションのデリゲート（AppDelegateやSceneDelegate）のライフサイクルイベントで明示的に呼び出すのが一般的です。

仕組み

AppDelegateのapplication(_:didFinishLaunchingWithOptions:)メソッドは、アプリケーションが起動してUIがユーザーに表示される前に呼び出されるため、アプリケーション全体で一度だけ実行したい初期化処理に最適です。

Swift

import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        print("Application did finish launching.")

        // アプリケーション全体で一度だけ実行したい初期化処理
        AppSetupManager.shared.performInitialSetup()

        // MyServiceの初期化をここで明示的にトリガーすることも可能
        // _ = MyService.shared 

        return true
    }
    // ... その他のデリゲートメソッド
}

// アプリケーション全体の初期化を管理するシングルトン
class AppSetupManager {
    static let shared = AppSetupManager()

    private init() {
        print("AppSetupManager instance created.")
        // ここでさらに複雑な初期化処理を行う
    }

    func performInitialSetup() {
        print("AppSetupManager is performing initial setup.")
        // 例: ログシステムの設定、ユーザーデフォルトの初期値設定など
    }
}

// 実行（AppDelegateのapplication(_:didFinishLaunchingWithOptions:)から呼ばれる）
// 出力:
// Application did finish launching.
// AppSetupManager instance created.
// AppSetupManager is performing initial setup.

メリット

• 明確な実行タイミング: アプリケーション起動時に一度だけ実行されることが保証されます。
• 集中管理: アプリケーション全体の初期化ロジックを一箇所に集約できます。
• 依存関係の制御: 必要なサービスやマネージャーを明示的に初期化し、依存関係を管理しやすいです。

デメリット

• +initializeのようにクラスが初めて使用される「直前」ではなく、「アプリ起動時」に実行されるため、タイミングが異なる場合があります。
• モジュールごとの初期化ではなく、アプリケーション全体としての初期化を目的とします。

3. Objective-Cランタイム機能を利用する（非推奨・特殊ケース）

SwiftはObjective-Cと相互運用性を持っていますが、純粋なSwiftクラスでObjective-Cランタイムの+initializeや+loadのようなメソッドを直接オーバーライドして使うことはできません。Swiftのクラスが@objc属性を持つObjective-C互換クラスである場合でも、+initializeや+loadはObjective-Cランタイムによってのみ呼び出されるメソッドであり、Swiftのクラスにはそのメソッドの概念が存在しません。

もし、Objective-Cで書かれた既存の+initializeメソッドを持つクラスをSwiftで利用する場合、そのクラスの+initializeはObjective-Cランタイムによって通常通り呼び出されます。しかし、Swiftのクラスで同等の振る舞いを「新しく」実装する必要がある場合は、前述のstatic letやアプリケーションライフサイクルイベントを利用すべきです。

@_silgen_nameのようなプライベートなアトリビュートや、モジュール初期化時のリンカーレベルのハックを試みることも可能かもしれませんが、これはSwiftの安定したAPIではないため、非推奨であり、将来のSwiftバージョンで動作しなくなる可能性があります。

ハマった点やエラー解決

static letの初期化が期待するタイミングで実行されない

static letは遅延初期化されるため、そのプロパティが初めて参照されるまで初期化コードは実行されません。これにより、特定の初期化処理がアプリケーション起動直後に走ってほしいのに、実際には後で実行されてしまうという事態が発生することがあります。

解決策: アプリケーション起動時など、初期化を確実に実行したいタイミングで、明示的にstatic letプロパティを参照します。

Swift

// 例: MyService.shared の初期化をアプリ起動時に確実に実行したい
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        _ = MyService.shared // ここで参照することで初期化をトリガー
        return true
    }
}

Objective-Cの+initializeのような継承チェーンを考慮した初期化がSwiftで実現できない

Objective-Cの+initializeは、スーパークラスから子クラスへと呼び出しが伝播しました。しかし、Swiftのstatic letによる初期化は、各クラスで独立しており、継承チェーンを自動的に考慮しません。

解決策: Swiftでは、クラスの初期化はinit()メソッドを通じて行うのが一般的です。もし継承関係を持つクラスで共通の初期化処理が必要な場合は、スーパークラスのinit()でその処理を行い、サブクラスのinit()でsuper.init()を呼び出すことで、継承チェーンに沿った初期化を実現します。静的初期化に関しては、各クラスで必要なstatic letを個別に定義し、必要に応じて明示的に呼び出す形になります。

まとめ

本記事では、Objective-Cの+initializeメソッドの概念と、Swiftでそれに相当する静的初期化処理を実現するための方法について解説しました。

• Swiftではstatic letとクロージャの組み合わせが最も推奨される静的初期化のアプローチです。 これはスレッドセーフで遅延評価され、コードの意図が明確になります。
• アプリケーション全体での初期化は、AppDelegateのライフサイクルイベントで明示的に実行するのが適切です。 これにより、アプリケーション起動時に必要なセットアップを集中管理できます。
• Objective-Cの+initializeや+loadのようなランタイムに深く依存する振る舞いをSwiftで直接再現することは、通常は推奨されません。Swiftの設計思想に沿った、より安全で明示的な方法を選択すべきです。

この記事を通して、Swiftでの静的初期化のベストプラクティスを理解し、Objective-Cからの移行や、新規Swiftプロジェクトでの効率的な初期化ロジックの設計に役立てていただけたなら幸いです。

参考資料

• The Swift Programming Language - Initialization
• Swift Evolution Proposal SE-0009: dispatch_once for static let
• Cocoa Core Competencies: +initialize vs +load