iOSアプリケーションの依存関係を正しく管理する：Typhoonの紹介

「十分に分析された魔法は、技術と見分けがつきません。」

アーサー・クラーク
（Typhoon Frameworkプロジェクトの公式wikiのエピグラフ）

サイクル「iOSアプリケーションの依存関係を正しく管理する」

• 台風の紹介
• 台風装置
• モジュラリティ台風
• 台風のヒントとコツ
• 台風の代替
• （オプション）Rambler.iOS＃3。 iOSでの依存性注入。 スライド
• （オプション）Rambler.iOS＃3。 iOSでの依存性注入。 映像

はじめに

このシリーズの記事の一部として、私は理論を掘り下げず、 依存性反転の原理または依存性注入のパターンを検討します-読者はすでにZenを学習する準備ができていることを当然と見なし、実践に直行します（理論に慣れるためのリンクはポストの最後）。

Typhoon Frameworkは、Objective-CおよびSwiftアプリケーション向けのDIコンテナの最も有名で人気のある実装です。 プロジェクトは非常に若いです-最初のコミットは2012年の終わりに行われましたが、すでに多くのファンを獲得しています。 作成者によるプロジェクトの積極的なサポート（そのうち1つはオムスクに住んでいます）は特筆に値します-作成された問題の大部分は10分以内に回答され、数時間後にチーム全体がディスカッションに参加します。

台風が必要なのはなぜですか？ 略語で答えます-IoC。 私はすでに理論に入らないことを約束しているので、 Martin Fowlerに言及するだけです。



Typhoonの主な機能をいくつか見てみましょう。これは、iOS開発者の注目を集めるのに十分なはずです。

• 絶対的かつ完全にネイティブ。 XML、マクロ、マジックラインはありません。Xcodeが提供するこれらの少数の利点はすべて、コンパイル段階でのリファクタリング、自動補完、コード検証を完全にサポートしています。
• モジュール性は非常に実装されています-垂直層と水平層の両方に分割された任意の数の工場で作業できます。
• Storyboardsと完全に統合されているため、依存関係をViewControllersに直接埋め込むことができます。
• すべての依存性注入パターンをサポートします ：イニシャライザー注入、プロパティ注入、メソッド注入（および後者のために、特別なフックも提供されます）。
• 循環依存関係の注入をサポート-例として、ViewControllerはオブジェクトを保持し、そのデリゲートです。
• 大きなバイナリを持つファイターは平和に眠ることができます-フレームワークのすべてのモジュールが占有するコードはわずか3,000行です （2つの通常のViewControllerのように）

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

Typhoonがクリーンなアプリケーションに簡単に統合できることを示すために、適切な方法でアプリケーションを構成できるAppDelegateでstartUpConfiguratorオブジェクトを実装する場合を考えます。

@interface RIAppDelegate @property (strong, nonatomic) id <RIStartUpConfigurator> startUpConfigurator; @end 

1. 独自のサブクラスTyphoonAssembly （DIコンテナー）を作成します。
   
   

    @interface RIAssembly : TyphoonAssembly - (RIAppDelegate *)appDelegate; @end 

   
   実際、このメソッドはインターフェイスで宣言されていない場合がありますが、教育目的のためにここに残しておきます。
   
   
2. RIAssemblyの実装を実装します。
   
   

    @implementation RIAssembly - (RIAppDelegate *)appDelegate { return [TyphoonDefinition withClass:[RIAppDelegate class] configuration:^(TyphoonDefinition *definition) { [definition injectProperty:@selector(startUpConfigurator) with:[self startUpConfigurator]]; } } - (id <RIStartUpConfigurator>)startUpConfigurator { return [TyphoonDefinition withClass:[RIStartUpConfiguratorBase class]]; } @end 

   
   コンフィグレータにTyphoonDefinitionを返すメソッドでは、追加の注入は実行されませんが、今後これが発生するのを防ぐものは何もないことに注意してください。 たとえば、アプリケーションのkeyWindowを渡して、 rootViewControllerを設定できます。
   
   
3. 定義上、DIコンテナーは可能な限り自動化する必要があります 。TyphoonAssemblyから何かを手動で要求することは望ましくありません。 最良のオプションは、 Info.plistファイルを使用することです。 私たちに必要なのは、特定のキーの下に、アプリケーションの起動時にアクティブ化する必要があるファクトリのクラスの名前を追加することです。
   
   
   
   これで設定全体が完了します。 最後に何が得られたか見てみましょう。
   
   
4. -applicationDidFinishLaunchingメソッドにブレークポイントを設定し、アプリケーションを実行します。
   
   
   
   コンフィギュレーターは、必要なクラスを正常に挿入しました（ RIAppDelegate自体は、定義したプロトコルに従って動作することを思い出してください）。

ご覧のとおり、Typhoonの基本的な統合には数分しかかかりません。 さらに、フレームワークを長い記述のアプリケーションに埋め込むことができますが、この場合、喜びの程度はコード設計の品質に依存します。

しかし、セットアップ手順に興味がある人は-RamblerプロジェクトでTyphoonを使用する実際のケースを見てみましょう。

Rambler。MailでのTyphoonの使用例

1. 特定のプロトコルを実装する単純なインスタンスを作成するには、作成したオブジェクトのクラスを指定するだけです。
   
   

    - (id <RCMStoryboardBuilder>)storyboardBuilder { return [TyphoonDefinition withClass:[RCMStoryboardBuilderBase class]]; } 

   
   
2. RCMAuthorizationPopoverBuilderBaseにはstoryboardBuilderオブジェクトが必要です。このオブジェクトは作成方法を既に学習しています。 依存関係グラフに挿入するには、適切なメソッド[self storyboardBuilder]を呼び出すだけです。 したがって、クラスのインスタンスを作成するだけでなく、そのすべての依存関係もインストールしました。
   
   

    - (id <RCMPopoverBuilder>)authorizationPopoverBuilder { return [TyphoonDefinition withClass:[RCMAuthorizationPopoverBuilderBase class] configuration:^(TyphoonDefinition *definition) { [definition injectProperty:@selector(storyboardBuilder) with:[self storyboardBuilder]]; }]; } 

   
   
3. RCMNetworkLoggerBaseクラスのオブジェクトをシングルトンにしたい-オブジェクトのライフサイクルの設定を担当するTyphoonDefinitionの scopeプロパティがこれに役立ちます。
   
   

    - (id <RCMLogger>)networkLogger { return [TyphoonDefinition withClass:[RCMNetworkLoggerBase class] configuration:^(TyphoonDefinition *definition) { definition.scope = TyphoonScopeSingleton; }]; } 

   
   
4. TyphoonがInitializer Injectionを実装する方法を見てみましょう。 動作するには、設定サービスには2つの必須の依存関係が必要です。ネットワーク要求を処理できるnetworkClientと 、さまざまなユーザー資格情報を格納するcredentialsStorageです。 TyphoonDefinitionの-useInitializerメソッドは、特定の初期化セレクターと、パラメーターが初期化子に埋め込まれているブロックを受け入れます。
   
   

    - (id <RCMSettingsService>)settingsService { return [TyphoonDefinition withClass:[RCMSettingsServiceBase class] configuration:^(TyphoonDefinition *definition) { [definition useInitializer:@selector(initWithClient:sessionStorage:) parameters:^(TyphoonMethod *initializer) { [initializer injectParameterWith:[self mailXMLRPCClient]]; [initializer injectParameterWith:[self credentialsStorage]]; }]; }]; } 

   
   
5. 次に、メソッドインジェクションの実装を調べてみましょう。 エラーサービスは、受信したNSErrorをすべての署名済みハンドラーに送信できます。 未処理のエラーがすべてログに記録されるようにするには、サービスを作成した直後に標準ハンドラーに署名します。
   
   

    - (id <RCMErrorService>)errorService { return [TyphoonDefinition withClass:[RCMErrorServiceBase class] configuration:^(TyphoonDefinition *definition) { [definition injectMethod:@selector(addErrorHandler:) parameters:^(TyphoonMethod *method) { [method injectParameterWith:[self defaultErrorHandler]]; }]; }]; } 

   
   
6. アプリケーションのすべてのViewControllersには、3つの依存関係が必要です。エラー処理サービス、受信したすべてのNSErrorオブジェクトが通過する、いくつかの一般的なエラーコードを適切に処理できる基本エラーハンドラ、および基本ルーターです。 すべてのコントローラーでこのコードの重複を避けるために、これら3つの依存関係をベースのTyphoonDefinitionに注入しました 。 他のメソッドで使用するには、単に親プロパティを設定します。
   
   

    - (UIViewController *)baseViewController { return [TyphoonDefinition withClass:[UIViewController class] configuration:^(TyphoonDefinition *definition) { [definition injectProperty:@selector(errorService) with:[self.serviceComponents errorService]]; [definition injectProperty:@selector(errorHandler) with:[self baseControllerErrorHandler]]; [definition injectProperty:@selector(router) with:[self baseRouter]]; }]; } - (UIViewController *)userNameTableViewController { return [TyphoonDefinition withClass:[RCMMessageCompositionViewController class] configuration:^(TyphoonDefinition *definition) { definition.parent = [self baseViewController]; [definition injectProperty:@selector(router) with:[self settingsRouter]]; }]; } 

   
   Typhoonを使用すると、TyphoonDefinitionsの継承のはるかに複雑なチェーンを構築できることに注意してください。
   
   
7. APIのURLをハードコーディングする代わりに、構成plistファイルに保存します。 この状況で、Typhoonは以下を支援します-必要なファイルをアップロードし、そのフィールドをネイティブオブジェクト（この場合はNSURL ）に変換し、 設定フィールドにアクセスするための便利な構文TyphoonConfig（KEY）を提供します。
   
   

    - (id)configurer { return [TyphoonDefinition configDefinitionWithName:RCMConfigFileName]; } - (id<RCMRPCClient>)idXMLRPCClient{ return [TyphoonDefinition withClass:[RCMRPCClientBase class] configuration:^(TyphoonDefinition *definition) { [definition useInitializer:@selector(initWithBaseURL:) parameters:^(TyphoonMethod *initializer) { [initializer injectParameterWith:TyphoonConfig(RCMAuthorizationURLKey)]; }]; }]; } 

   
   

神話

Typhoon Frameworkに表面的にのみ興味を持っている人の中には、事実上基礎がないいくつかの神話があります。

1. 高いエントリーしきい値
   実際、ソースコード、ドキュメント、サンプルプロジェクト（ちなみに既に3つあります）を掘り下げると、Typhoonの基本原則を理解し、プロジェクトで使用を開始できます。 深く掘り下げたくない場合は、例を使わずに、フレームワークをコードに遅滞なく統合できます。
   
   
2. デバッグへの強い影響
   実際、私たちのコードとTyphoonの間には実際の連絡先はそれほど多くありません。これらの分岐点では、開発者は既に有益な例外を持っています。
   
   
3. Typhoonがサポートを停止した場合、プロジェクトから除外しない
   台風は、私たちが実際にどこでも直接対話しないため、良いです-したがって、それを拒否することは困難ですが、それでも可能です-自分のレベルの工場とそれをコードと統合するためのメカニズムを手動で作成してください。
   
   
4. しかし...スウィズルもあります！
   Objective-Cはそのランタイムで有名であり、そのようなフレームワークでその機能を使用しないことは少なくとも愚かです。 さらに、このコンポーネントを「ブラックボックス」として使用します。これは、同じ1200のスターがすべてのレーキをすでに踏んでいるという事実に依存しています。
   
   
5. 自転車を書くことができるのになぜTyphoonが必要なのですか？
   Typhoon Frameworkは、画面間を移動するときにオブジェクトのグラフを作成し、依存関係を渡すコードの量と複雑さを大幅に削減します。 さらに、セルフサービスのサービスロケーターの不利な点なく、集中管理された依存関係管理を提供します。 読者は誰でも簡単なファクトリーを作成できると思いますが、プロジェクトが発展するにつれて、このアプローチの制限に直面し続けることになります-そして、長い間考え出してデバッグしたものを実装するか、プロジェクトの機能とパフォーマンスを犠牲にする必要があります。

おわりに

当初、私はRambler.iOSでのスピーチを完全に翻訳して印刷するつもりでしたが、2、3のセクションを書いた後、1つの記事には資料が多すぎることに気付きました。 したがって、次のシリーズでは：

サイクル「iOSアプリケーションの依存関係を正しく管理する」

• 台風の紹介
• 台風装置
• モジュラリティ台風
• 台風のヒントとコツ
• 台風の代替
• （オプション）Rambler.iOS＃3。 iOSでの依存性注入。 スライド
• （オプション）Rambler.iOS＃3。 iOSでの依存性注入。 映像

便利なリンク

• 公式サイトTyphoon Framework
• Typhoon Framework Wiki
• objc.io＃15：依存性注入
• DI vs DIP vs IoC
• 依存関係の逆転の原則
• コントロールコンテナの反転と依存性注入パターン