すべての良い一日。 困難な時期には、常にストレスの多い状況に対処する必要があり、プログラムコードの作成も例外ではありません。 誰もがさまざまな方法でストレスに対処します。誰かがバーに行き、誰かが沈黙の中で反対に瞑想しますが、誰もがこのストレスを可能な限り低くし、意図的にストレスの多い状況を避けようとします。



Swiftで書き始めたとき、私は多くの問題に直面しなければなりませんでしたが、その1つは、この言語でのIoCコンテナー間の競合がないことです。 実際、台風とスウィンジェクトの2つしかない。 Swinjectには機能がほとんどなく、TyphoonはObj-C向けに書かれていますが、これは問題であり、それを扱うことは私にとって大きなストレスになることが判明しました。



そして、Ostapが苦しんだので、 Swift用のIoCコンテナーを書くことにしました。



だから、知り合いになる-DITranquillity 、Swift上のiOS用IoCコンテナー、ストーリーボードと統合。



名前についての興味深い話-何百もの異なるアイデアの後、私は「穏やか」に落ち着きました。 名前を思いついたとき、IoCコンテナーを作成する主な理由はTyphoonであるという事実から始めました。 最初は、図書館を台風よりも強い自然災害と呼ぶことについて考えていましたが、台風はストレスであり、私の図書館は反対、つまり平和を提供するべきだと私は違った考え方をしなければならないことに気付きました。



すべてを静的にチェックすることを計画しました（残念ながら、すべてが完全に失敗しました）。また、大きなアプリケーションで台風を使用する場合、頻繁に発生せず、台風のためにxcodeがプロジェクトを収集しないという何らかの理由でアプリケーションの途中に落ちないようにしましたが、アセンブリ中にクラッシュします。



台風愛好家は少し動揺するかもしれませんが、私の意見では、一部のエンティティの命名は台風の命名とは異なります。 Autofacと同じですが、言語の特性を考慮に入れています。

特徴

ライブラリの機能を説明することから始めます。

• このライブラリは、純粋なSwiftクラスで動作します。 NSObjectから継承してプロトコルをObj-Cとして宣言する必要はありません。このライブラリを使用すると、純粋なSwiftで記述できます。
• ネイティブ性-依存関係の記述はネイティブ言語で行われます。これにより、簡単なリファクタリングと...
• コンパイル段階でのほとんどのチェック-Typhoonの後、これは楽園のように見えるかもしれません。多くのタイプミスが実行時ではなくコンパイル段階で検出されるためです。 残念ながら、ライブラリは実行中にエラーを自慢することはできませんが、問題の一部は確実に遮断されます。
• すべての依存性注入パターンのサポート：イニシャライザー注入、プロパティ注入、メソッド注入。 なぜこれがクールなのかわかりませんが、誰もがそれについて書いています。
• 循環依存関係のサポート-ライブラリは、プログラマーの介入なしに、循環依存関係のさまざまなオプションをサポートします。
• ストーリーボードとの統合-ViewControllersに直接依存関係を埋め込むことができます。

そしてまた：

• オブジェクトの存続期間のサポート。
• 代替タイプの表示。
• タイプと名前による依存関係の解決。
• 複数登録;
• 初期化パラメーターを使用した依存関係の解決。
• 依存関係を解決するための短いエントリ。
• 「モジュール性」の特別なメカニズム。
• CocoaPodsのサポート。
• ロシア語のドキュメンテーション（実際には、ドキュメンテーションのドラフトと言う方が正確です。多くのエラーがあります）。

そして、これらはすべて1500行のコードで、そのうち約400行で、異なる数の初期化パラメーターを持つ依存関係の型指定された解決のために自動的に生成されたコードです。

そして、これらすべてをどうするか？

簡単に

私は小さな構文の例から始めます： Autofacは私のライブラリに適合した例を書くことを許してくれます 。

// Classes class TaskRepository: TaskRepositoryProtocol { ... } class LogManager: LoggerProtocol { ... } class TaskController { var logger: LoggerProtocol? = nil private let repository: TaskRepositoryProtocol init(repository:TaskRepository) { self.repository = repository } ... } // Register let builder = DIContainerBuilder() builder.register(TaskRepository.self) .asType(TaskRepositoryProtocol.self) .initializer { TaskRepository() } builder.register(LogManager.self) .asType(LoggerProtocol.self) .initializer { LogManager(Date()) } builder.register(TaskController.self) .initializer { (scope) in TaskController(repository: *!scope) } .dependency { (scope, taskController) in taskController.logger = try? scope.resolve() } let container = try! builder.build() // Resolve let taskController: TaskController = container.resolve()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして今、順番に

基本的なプロジェクト統合

Typhoonとは異なり、ライブラリはplistまたは同様の「機能」からの「自動」初期化をサポートしていません。 原則として、台風はそのような機会をサポートしているという事実にもかかわらず、私は彼らの便宜について確信が持てません。



多かれ少なかれ計画されているプロジェクトと統合するには、次のものが必要です。

1. ライブラリ自体をプロジェクトに統合します。 これは、Cocoapodsを使用して実行できます。
   
   
   
   

    pod 'DITranquillity'
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
2. ライブラリを使用してベースアセンブリを宣言します（オプション）：
   
   
   
   

    import DITranquillity class AppAssembly: DIAssembly { //    var publicModules: [DIModule] = [ ] var intermalModules: [DIModule] = [ AppModule() ] var dependencies: [DIAssembly] = [ // YourAssembly2(), YourAssembly3() -     ] }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
3. 基本モジュールを宣言します（オプション）：
   
   
   
   

    import DITranquillity class AppModule: DIModule { //    func load(builder: DIContainerBuilder) { //     //   } }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

   
   
   
4. モジュールのタイプを登録します（上記の最初の例を参照）。
   
   
   
   
5. ビルダーにベースアセンブリを登録し、コンテナーを組み立てます。
   
   
   
   

    import DITranquillity @UIApplicationMain class AppDelegate: UIResponder, UIApplicationDelegate { public func applicationDidFinishLaunching(_ application: UIApplication) { ... let builder = DIContainerBuilder() builder.register(assembly: AppAssembly()) try! builder.build() //   //      ,   ,    ,    } }
         
         
   
           
           
           
         
   
       
           
           
           
         
         
   
           
           
           
         
   
       
        

絵コンテ

いくつかのクラスを作成した後の次のステップは、Storyboardを作成することです（まだ行っていない場合） 。 依存関係に統合します。 これを行うには、ベースモジュールを少し編集する必要があります。

 class AppModule: DIModule { func load(builder: DIContainerBuilder) { builder.register(UIStoryboard.self) .asName("Main") //            .instanceSingle() //         .initializer { scope in DIStoryboard(name: "Main", bundle: nil, container: scope) } //    } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

AppDelegateを変更します。

 public func applicationDidFinishLaunching(_ application: UIApplication) { .... let container = try! builder.build() //    window = UIWindow(frame: UIScreen.main.bounds) let storyboard: UIStoryboard = try! container.resolve(Name: "Main") //   Main storyboard window!.rootViewController = storyboard.instantiateInitialViewController() window!.makeKeyAndVisible() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ストーリーボード上のViewControllers

そして、コードを実行し、 何も落ちていないことを嬉しく思い 、ViewControllerを作成したことを確認しました。 いくつかのクラスを作成し、ViewControllerに実装します。



プレゼンターを作成します。

 class YourPresenter { ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、ViewControllerに名前（タイプ）を指定し、プロパティまたはメソッドを介してインジェクションを追加する必要がありますが、コードではプロパティを介したインジェクションを使用します。

 class YourViewController: UIViewController { var presenter: YourPresenter! ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、ストーリーボードで、ViewControllerがUIViewControllerだけでなくYourViewControllerであることを忘れないでください。



そして、モジュールに型を登録する必要があります。

  func load(builder: DIContainerBuilder) { ... builder.register(YourPresenter.self) .instancePerScope() // ,    scope    Presenter .initializer { YourPresenter() } builder.register(YourViewController.self) .instancePerRequest() //     ViewController' .dependency { (scope, self) in self.presenter = try! scope.resolve() } //   }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

プログラムを開始すると、ViewControllerにプレゼンターがいることがわかります。



しかし、ちょっと、instancePerRequestの奇妙な存続期間と、イニシャライザーはどこに行きましたか？ Storyboardに配置される他のすべてのタイプのViewControllerとは異なり、Storyboardを作成するのではなく、Storyboardを作成するため、初期化子はなく、初期化メソッドを介したインジェクションをサポートしません。 イニシャライザの存在は、コンテナを作成する際のチェックポイントの1つであるため、このタイプは私たちではなく、他の誰かによって作成されることを宣言する必要があります。

データを使用した作業を追加する

その後、プロジェクトは何かをする必要があります。多くの場合、モバイルデバイスに対して、アプリケーションはネットワークから情報を受け取り、処理して表示します。 簡単にするために、データ処理ステップを省略し、ネットワークからデータを受信する詳細には触れません。 `get`メソッドを備えたServerプロトコルがあり、それに応じてこのプロトコルの実装があると仮定します。 つまり、次のコードがプログラムに表示されます。

 protocol Server { func get(method: String) -> Data? } class ServerImpl: Server { init(domain: String) { ... } func get(method: String) -> Data? { ... } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、新しいクラスを登録する別のモジュールを作成できます。 もちろん、さらに先に進んで新しいアセンブリを作成し、サーバーでの作業を別のプロジェクトに転送することもできますが、この例は複雑になりますが、ライブラリのより多くの側面と機能が示されます。 または、逆に、既存のモジュールに埋め込みます。

 import DITranquillity class ServerModule: DIModule { func load(builder: DIContainerBuilder) { builder.register(ServerImpl.self) .asSelf() .asType(Server.self) .instanceSingle() .initializer { ServerImpl(domain: "https://your_site.com/") } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ServerImpl型を登録しました。プログラムでは、ServerImplとServerという2つの型で認識されます。 これは登録動作のいくつかの機能です。代替タイプが指定されている場合、明示的に指定されない限り、メインタイプは使用されません。 また、プログラムにはサーバーが1つしかないことも示しました。



また、アセンブリを少し変更して、彼女が新しいモジュールを認識できるようにします。

 class AppAssembly: DIAssembly { var publicModules: [DIModule] = [ ServerModule() ] }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Presenterを少し修正しましょう。サーバーが必要な情報を彼に追加します。

 class YourPresenter { private let server: Server init(server: Server) { self.server = server } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

初期化メソッドを使用して依存関係を実装しましたが、ViewControllerの場合のように、プロパティまたはメソッドを使用して実装できます。



そして、プレゼンターの登録を完了しています-プレゼンターにサーバーを実装すると言います。

  builder.register(YourPresenter.self) .instancePerScope() // ,    scope    Presenter .initializer { (scope) in YourPresenter(server: *!scope) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、「高速」構文 `*！`を使用して、依存関係を取得しました。これは、表記法と同等です： `try！ scope.resolve（） `



プログラムを起動し、プレゼンターにサーバーがあることを確認します。 これで使用できます。

ロガーを実装します

私たちのプログラムは動作しますが、一部のユーザーにとっては、突然正しく動作しなくなりました。 自宅で問題を再現して判断することはできません-それはいつでも、ロガーが必要です。 しかし、超常現象に対する私たちの信念は既に覚醒しているので、ロガーはファイル、コンソール、サーバー、さらには海の場所にデータを書き込む必要があり、これらすべてを簡単にオン/オフして使用する必要があります。



そのため、関数log（メッセージ：文字列）を使用して基本プロトコル `Logger`を作成し、いくつかの実装を実装します。ConsoleLogger、FileLogger、ServerLogger ...その他すべてをプルする基本ロガーを作成し、MainLoggerと呼びます。 さらに、ログを記録するクラスでは、類似性に関する行を追加します： `var log：Logger？ = nil`、および...そして、実行したすべてのアクションを登録する必要があります。



最初に、新しいLoggerModuleモジュールを作成します。

 import DITranquillity class LoggerModule: DIModule { func load(builder: DIContainerBuilder) { builder.register(ConsoleLogger.self) .asType(Logger.self) .instanceSingle() .initializer { ConsoleLogger() } builder.register(FileLogger.self) .asType(Logger.self) .instanceSingle() .initializer { FileLogger(file: "file.log") } builder.register(ServerLogger.self) .asType(Logger.self) .instanceSingle() .initializer { ServerLogger(server: "http://server.com/") } builder.register(MainLogger.self) .asType(Logger.self) .asDefault() .instanceSingle() .initializer { scope in MainLogger(loggers: **!scope) } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、たとえば次のように、ロガーの導入を宣言したすべてのクラスに追加することを忘れないでください。

 builder.register(YourPresenter.self) .instancePerScope() // ,    scope    Presenter .initializer { scope in try YourPresenter(server: *!scope) } .dependency { (scope, obj) in obj.log = *?scope }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして、それをアセンブリに追加します。 今、私たちが書いたばかりのものを作る価値があります。



最初に、3つのロガーを登録しました。これは、ロガーという名前で利用できます。つまり、複数の登録を実行しました。 さらに、MainLoggerを削除すると、プログラムは1つのロガーを持たなくなります。1つのロガーを取得したい場合、ライブラリはプログラマがどのロガーを望んでいるかを理解できないためです。 次に、MainLoggerに対して2つのことを行います。

1. これは標準のロガーだと言います。 つまり、単一のロガーが必要な場合、それはMainLoggerであり、他のロガーではありません。
   
   
   
   
2. MainLoggerでは、自分自身を除くすべてのロガーのリストを転送します（これはライブラリの機能の1つであり、複数の依存関係を解決できるため、再帰呼び出しは除外されます。これは、「try！」に相当する高速構文「**！」を使用します。 scope.resolveMany（） `

まとめ

ライブラリを使用して、ルーター、ViewController、プレゼンター、データなどの複数のレイヤー間の依存関係を構築することができました。 プロパティを介して依存関係を注入する、初期化子、代替タイプ、モジュールを介して依存関係を注入する、ライフタイムとアセンブリにわずかに触れるなどのことが示されました。



多くの機会が失われました：周期的な依存関係、名前、ライフタイム、アセンブリによる依存関係の取得。 それらはドキュメントで見ることができます。



この例は、 このリンクから入手できます。

計画

• 詳細なログを追加し、ログが送信される外部機能を指定する機能
• 他のシステムのサポート（MacOS、WatchOS）

代替案

• 台風 -純粋な迅速型をサポートしておらず、その構文は私の意見では面倒です
• Swinject-代替タイプの欠如、および複数の登録。 「モジュール性」のメカニズムはあまり開発されていませんが、これは優れた代替手段です