短剣2. Googleを使用した依存症の治療

投稿者：コンスタンティン・マーズ

シニア開発者@ DataArt、

共同オーガナイザー@ GDG Dnipro

依存性注入

何が、なぜ、いつ必要なのか

今日は、Androidの開発の品質を向上させるのに役立つツールについてお話します。 この問題は、依存性注入（DI）を使用して解決できます。 通常、この用語は注射、注射器、および「中毒」と少し関連しています。 実際、依存性注入は、依存性反転の原理を実装し、オブジェクトの作成と実装の独立性のルールを実装する設計パターンです。

そのため、クラスがあり、クラスにはコンストラクターがあり、クラスのメンバーがいくつかあります。 このクラスの本質を作成するとき、そのメンバーに対して宣言されているまさにその型のインスタンスをクラスに提供する必要があります。 この場合、これはマシンの名前とエンジンEngineのタイプです。 オブジェクトへのリンクを使用するため、クラス内のリンクは空になりません。

したがって、OOPを実装し、オブジェクトを作成できます。

クラスを作成する...

• 構成は継承ではありません。
• リンクは空になりません。

オブジェクトを作成する機能...

オブジェクトを作成し、マシンの名前を設定し、新しいエンジンを作成できます。







異なるオブジェクトを作成できます。たとえば、異なるタイプのエンジンや別のエンジンのみを作成できます。







使用する2つの異なるオブジェクトを作成できるとします。 この場合、パトリオットの同じエンジン。 したがって、このエンジンをジープグランドチーロキーに配置すると、少し奇妙になります。 しかし、それでも、あなたはそれをすることができます。 この場合、作成するエンティティが別のエンティティに含まれる場合、いわゆる「構成」パターンが使用されます。これは、ご覧のとおり、継承ではなく構成です。







ここではすべてが非常に簡単です：SuperTunedEngineを見ると、実際にはそれが特定の型の継承者であり、事前に宣言されており、おそらくインターフェースの実装であることがわかります-私たちにとってこれは無理です。 この場合、エンジンはインターフェースである可能性があります。







2つの広告を見ると、2つのオブジェクトを他のオブジェクトに依存させることができます。 実際、これは依存関係です。 したがって、オブジェクトを作成する機能は依存関係を作成します-これはかなりありふれたことです。

そして...中毒

車はエンジンに依存しています。 エンジンは異なる場合があります。 おそらくテストと実稼働用に異なるエンジンが必要になります。







図からわかるように（画像はこの例ではありません）、依存関係は非常に異なります。 依存サービス、依存アクティビティ、プレゼンター、ビュー、コントローラーがあります。 これらのすべてのエンティティは、依存関係によって絡み合っています。 グラフィカルに表現しようとすると、今見ているものが絵に現れます。

実際の稼働中のシステムには、はるかに多くの依存関係があります。 Androidアプリケーションをテストするためのツールを提供する有名な企業によって実施されたテストは、単純な一見したアプリケーションでも、数千の依存関係があることを示しています。 最も単純なアプリケーションでも、平均して数千から数万の依存関係が見つかります。 これらの依存関係を可能な限り効率的に実装し、クラス内の他のクラスをインスタンス化せずに、繰り返し作業を追加して余分な作業を追加するコードを追加することなく、Daggerツールがあります。

ダガーとJSR-330標準

抽象注入

ダガーはJSR-330標準に基づいています。 Googleは長い間この標準を使用しており、Javaインジェクションの標準です。

ほとんどない歴史  

• ダガー2-Google、グレッグキック
• ダガー-スクエア、ジェイクワーソン
• Guice-Google、Jesse Wilson

少し歴史を見てみましょう。GoogleはかつてGuice（一般に「Juice」と呼ばれ、緯度では「Goose」と呼ばれます）のような製品を作成しました。 Guiceはリフレクションで作業し、注釈に従っていましたが、その後Squareの開発者はGuiceにあるシステムを改善し、Dagger1を作成しました。

Dagger1はクールなツールでしたが、実践が示すように、ここで何かを改善できます。 ちなみに、Dagger1も反射を使用しました。 そして、2015年に、Google開発者はDagger2をリリースしました。 ちょうど最近、Jake Wharton（Square社の有名な開発者）が秋に目を向けてリリースを発表したようです-約束が満たされ、テスト結果に基づいて競争に勝る高品質の製品があります。

制御の反転（IoC）

標準と用語に戻ります。 そのため、進化の過程で登場した製品があります。 多数の注釈を提供するJSR-330を使用します。 さらに、ある種の開発パターンである特定の原則に従います。その1つは、Inversion of Control（IoC）です。

ソフトウェアコンポーネントに外部依存関係を提供するプロセスは、依存関係管理に適用される場合の「制御の反転」（IoC）の特定の形式です。 単一責任の原則に従って、オブジェクトは、この一般的なメカニズム用に特別に設計された外部への必要な依存関係の構築に注意を払います。

このことは、アーキテクチャパターンに関連しています。 アプリケーションがインターフェイスに基づいて記述されるように、ドメインロジックに関連付けられた内部クラスが外部クラスから独立するようにアプリケーションを記述する必要があります。 したがって、責任範囲の区別が実現されます。 ある種の実装に目を向けると、まずインターフェースに目を向けます。 制御の反転は、依存性注入によって実装され、ツールキット自体は依存性注入（DI）と呼ばれます。

リフレクションとコンパイル時間

• Dagger2 vs Dagger1

Dagger2は、リフレクションを使用したDagger1とは異なり、コード生成を使用します。

JSR-330

JSR-330別名javax.inject

• 注入 、 修飾子 、 スコープ 。 など
• 標準化された依存性注入API
• 参照実装：Google Guice 2.0
• 3.0以降のSpringでもサポート
• インジェクターの実装または構成ではなく、APIを定義します

JSRは、 Inject注釈を記述するだけでなく、エンティティーが対話して依存性注入を提供する方法を宣言できる注釈のパッケージ全体も提供します。

たとえば、この標準に従う特定の依存性注入製品ファミリについて説明します。 この標準に準拠していない他の製品もあります。今日はそれらについて説明しませんが、それらは存在します。 Inject 、 Qualifier 、 Scopeがあります -それらについては後で説明します。 これらの注釈は、Dagger2に対してのみ作成されたものではなく、Guiceなどの他のインジェクターに対しても存在します。

それで、コードに魔法を加える時が来ました...

クラスメンバーに注釈injectで注釈を付けることから始めます。 すべてが非常に簡単です。 将来これらの依存関係をインスタンス化するために、Dependency Injectionツールキットは、インスタンス化する場所と対象を正しく選択できました。コンストラクターに注釈を付ける必要もあります。 ここで、状況はもう少し興味深いものになります。

デフォルトのコンストラクターに注意してください

インジェクションを提供する最も簡単な方法は、デフォルトのコンストラクターを作成することです。 次に、デフォルトのコンストラクター自体と、このクラスのインスタンス化をインジェクションで必要とするメンバーに注釈を付けます。 これは非常に簡単です。

パラメーター付きコンストラクター-変更に適した場所

実際には、パラメーターを持つコンストラクターが必要です。 システムは、デフォルトのコンストラクターがある場合、それらの一部を自動的に取得できます。 また、たとえば、同じエンジンを手動で構築する必要がある場合もあります。

また、このようなコンストラクタを使用してプレゼンターを注入します;これは、MVP（Model-View-Presenter）で非常によく使用されます。

そしてまだ-それを機能させる方法は？

Dagger2.0の注入構造

インジェクションフレームワークは、Daggerコンポーネントの相互接続であり、インジェクションアノテーションとクラス宣言を組み合わせることができます。

コンポーネントとモジュール

写真 著者-AzimoのMiroslaw Stanek

http://frogermcs.github.io/dagger-graph-creation-performance/

ダガー注入構造には、コンポーネントとモジュールが含まれます。 写真（AzimaのMiroslav Stanekによる記事）を見ると、コンポーネントはモジュールのコンテナであり、1つのコンポーネント内に他のコンポーネントがある可能性があります。 後で、ネストされたコンポーネントがサブコンポーネント（@Subomponent）と呼ばれることがわかります。 そして、注入の規則に従って、それらを単に「コンポーネント」と呼ぶことはできません。

モジュール-ジェネレーターコレクション

抽象モジュール -このエンティティ（このクラス）はオブジェクトのインスタンスを生成するモジュールであることを示す注釈。

ここでも、すべてが非常に簡単です。 生成する注釈は、提供注釈です。 提供アノテーションは、このモジュールメソッドがエンティティを提供することを単に示しています。 最も興味深いのは、このメソッドの内部です。

これらのルールに従って、何らかの方法でオブジェクトをインスタンス化する必要があります。 一部のオブジェクトは互いに依存します。 一部のオブジェクトは、モジュールに保存できるモジュールクラスのメンバーに依存します。 たとえば、同じコンテキストをモジュールに配置できます。 モジュールはそれを記憶し、同じプレゼンターをインスタンス化するときに、モジュールが作成されたときに一度記憶したコンテキストに基づいて新しいプレゼンターエンティティを生成します。

ご覧のとおり、モジュールにはコンストラクターがあります。 この場合、コンテキストの代わりにApplicationを渡します。 新しいものを作成するとき、モジュール自体に保存されているものを返すことができます。

シングルトンとは何ですか？

いくつかのエンティティを作成するとき、特定のパラメーターを設定します。 シングルトン（英語シングルトン ）-インジェクターが注釈インジェクトを見つける場所、彼は新しいオブジェクトをインスタンス化するべきではなく、既にインスタンス化されたシングルトンオブジェクトを再利用するべきであるという指示。

@コンポーネント

コンポーネント-モジュールのホスト、クラスのインジェクター、依存関係ツリーのルート。







このコンポーネントを使用すると、すべてが少し面白くなります。 コンポーネントは、含まれるモジュールの寿命を考慮する必要があります。 インスタンス化の有効期間を使用するコンポーネントにシングルトンを使用しようとすると、競合が発生します。 したがって、たとえば、Applicationクラスのオブジェクトは単一のインスタンスに存在し、アプリケーションの存続期間全体に存在するため、Applicationのコンポーネントはシングルトンになることを明確に理解する必要があります。 たとえば、アクティビティの場合、シングルトンにすることもでき、その有効期間はアクティビティの有効期間に関連付けられます。 必要に応じて、追加のシングルトン注釈を使用してコンポーネントに注釈を付けることができます。 このコンポーネントを含むモジュールのリストがあります。

たとえば、アクティビティには注入アノテーションがあります。 コンポーネントは、このアクティビティを提供するモジュールを指定する必要があります。 コンポーネントで注入する場所を指定する必要があります。 つまり、特定のクラスを指定する必要があります。たとえば、BaseActivityを基本クラスとして記述できないことに注意してください。これは、注入がBase aActivityおよびMainActivityでのみ発生するためです。プレゼンター、ルールは少し異なります。







injectメソッドは、誰が依存しているかの説明です。 モジュール-依存関係を提供する人の説明。

モジュールに戻りましょう。 モジュールはクラスとして宣言されます。 モジュールは、実際のオブジェクトへの実際の参照を持つ実際のクラスであることに注意することが重要です。 そして、コンポーネントを宣言するとき、バンドルするとき、手動で作成します。 コンポーネントは、Daggerが生成するオブジェクトです。 この瞬間、コード生成の魔法が起こります。 したがって、コンポーネントはインターフェイスとして宣言されます。

生成されたコードを使用したコンポーネントの初期化

たとえば、DaggerAppComponentはアプリケーション内で初期化されます。 使用される生成コード（コンポーネントの初期化）は、生成コードを使用することを意味することに注意してください。 たとえば、DaggerAppComponentを検出できます。 前に見たように、Daggerプレフィックスはありませんでした。 彼はどこから来たの？ はい、ダガーはコードを生成しました。 彼はそれを十分に速く生成します。 私たちが話している注入（その構造について）を誤って中断すると、DaggerAppComponentになってしまいます。 少し間違えてクラスを誤って指定すると、生成は機能しません-DaggerAppComponentは表示されず、アクティビティと他のクラスをバインドする魔法はすべて、生成されたクラスなしでは機能しません。 コンポーネントはツリー全体のルートであるため、これが基盤です。 そして、それなしでは、他のすべては機能しません。 以前にインジェクションをどのように構築するかに注意し、コンポーネントを正しく使用する必要があります。

コンポーネントにはビルダーがあることにも注意してください。 ビルダー-デザインパターン。 ビルダーには、コンポーネントをさらに構築する方法を決定するいくつかの引数、たとえばAppModuleメソッド（AppModuleインスタンスクラスを引数として取得する自動生成メソッド）があることを理解しています。 手でモジュールを作成し、そのパラメーターを設定します。 そしてbuildメソッドを呼び出してAppComponentを取得します。 このリンクには、実際のコードの例があります： http : //github.com/c-mars/Dagger2Scopes.git

これを注入してください！ :)

Puttin 'magicはインジェクション後にのみ機能します...

Applicationクラスには、それへのアクセスを提供するメソッドがあります。 さらに、これは静的メソッドではなく、getアプリケーションからコンテキストを取得するだけです。 クラスに追加することができます-同じ結果になり、ここには魔法はありません。 しかし、これは私たちにとって非常に重要であり、このgetAppComponentがあります。

アイデアは、アプリケーションがAppComponentを保存することです。 このコンポーネントでいくつかの追加メソッドを呼び出してから、注入メソッドを適用します。 お気づきのように、これはコンポーネントで宣言した特定のクラスを示す注入です。 この場合、それはLoginActivityクラスです。 アノテーションにインジェクションが表示されます。依存関係をどのようにインジェクトしたかを確認してください。 魔法は注射後にのみ機能します。

カスタムスコープと効率的なメモリ管理

したがって、カスタムスコープは、インスタンス化されたクラスに特定の有効期間を提供するのに役立ちます。

オブジェクトのライフサイクル

写真 著者-AzimoのMiroslaw Stanek

http://frogermcs.github.io/dagger-graph-creation-performance

たとえば、あなたが活動をしていて、彼らが十分に長く生きていない場合、画面上のものから別のものに行き、すべてを殺します。 つまり、アクティビティに注入されたすべてのものはその後クリーンアップでき、アプリケーションはより少ないメモリを消費します。 ユーザーなどのユーザーデータのクラスは、ログイン間で有効です。 アプリケーションスコープは、最も重要なルートスコープであり、最も長く存続します。

そして再び同じ入れ子人形

コンポーネントにはスコープがあります

写真 著者-AzimoのMiroslaw Stanek

http://frogermcs.github.io/dagger-graph-creation-performance/

この神秘的な「プラス」...

では、プラスに注目しましょう。

サブコンポーネント宣言

スコープアノテーションを使用すると、特定のライフタイムのスコープを生成できます。 たとえば、ActivityScopeは、アクティビティが存続する限り存続します。 コンポーネントにサブコンポーネントとして注釈を付けます。

しかし、モジュールがありました！

内部のデータは、ルートコンポーネントと同じ方法で記述されます。 1つのことを除いて、plusを呼び出し、そこにモジュールを渡してインスタンス化すると、必要なサブコンポーネントが取得されます。

依存関係ツリーのルートにサブコンポーネントを追加する

それは何のために使われますか？ そのため、インターフェイスとして宣言できるスコープは、オブジェクトの寿命を制限します。

抽象スコープ

この種類のスコープは、注入先に応じて、ライフタイムを静的に制限します。 そして、もう一方は動的に制限されます。

動的とは、手動で管理することを意味し、ガベージコレクター （「ガベージコレクター」）を使用してすべてが削除されます。

スコープに必要なコンポーネントに注釈を付けます。

@ActivityScope

@UserScope、たとえば、@ Retention（RUNTIME）を持つこの同じスコープの動作方法。 手動で制御できます。

@UserScope

手動で管理するには、アプリケーション内のコンポーネントへのリンクをAppComponentの隣に保存します。







特別なメソッドを使用して作成されます。これは、コードの例です。 その後、コードはクリーンアップされてリリースに送信され、ガベージコレクターはそれを削除します。 これはいつ起こりますか？ ユーザーがログアウトしたとき （ "logged in" ）。 次回、別のcreateUserComponentを呼び出すと、このコンポーネントは他のユーザーデータで再度作成されます。

最後に...何を注入しますか？

• デモデータモジュール。
• プレゼンター。
• シングルトン。
• クラスの実装をテストします。
• ...依存関係をインスタンス化して作成する他のすべて。

実際、メモリをより効率的に注入し、コードを記述するのに役立つ何かを注入する必要があります。 プレゼンターは必ず使用する必要があります。

シングルトンは便利です。 ここで紹介する例では、デモバージョンのモックデータを挿入しましたが、テスト中にバリエーションを使用することもできます。  

ホームリーディング

サンプルコード： http : //github.com/c-mars/Dagger2Scopes.git

• フェルナンド・セハス「Androidのテイスティングダガー2」：
  
  http://fernandocejas.com/2015/04/11/tasting-dagger-2-on-android/

• ミロスラフ・スタネク「ダガー2-graf creation performance /：
  
  http://frogerms.github.io/dagger-creation-performance/

• Dagger2公式ページ：
  
  http://google.github.io/dagger/

デザインパターンについてはFernando Cejasを読むことをお勧めします。 Miroslav Stanekはスコープを非常によく説明しました。 彼は、@ Retention（RUNTIME）を適切に管理し、時間内にメモリを消去する方法に関する素晴らしい記事を持っています。 そしてもちろん、公式のDagger2ページをご覧ください。

コードの意味

Mockモジュールを使用して高速アジャイル開発を編成し、最終的にサーバー側を追い抜いた方法。

物語はそのようなものです。 ユニットテストプロジェクトでは、正しいMVP分離を使用してDagger 2を使用しましたが、重要な点は、その時点ではサーバー側がなかったことです。 そして、データを分析して、サーバーからデータを取得、表示、処理するアプリケーションを作成しました。 主なタスクは、RESTサービスの出現により、RESTサービスにすばやく切り替えることができることでした。 コードを手動で変更することによってのみ、これを迅速に行うことができます。 モジュールとコンポーネントの可用性により、サーバーが登場した後、モックデータ（インジェクションによって提供された）をREST APIからの実際のデータに簡単に置き換え、ルートコンポーネントの宣言内の1つのモジュールと1行のコードのみを置き換えました。