ダガー2.サブコンポーネント。 ベストプラクティス

habrにはすでにインストールとDagger 2の操作に関する優れた記事がいくつかありました。

• パート1：基本
• パート2：サブコンポーネント

実際のプロジェクトでDagger 2を使用した経験を実際のケースと共有したいと思います。 ダガー自体とサブコンポーネントなどの側面の両方の力と利便性を読者に明らかにする。

あなたがカットの下に行く前に、あなたは上記の記事に慣れる必要があります。
誰に興味がありますか？

私の友人は、すべてを棚に置く素晴らしい方法を教えてくれました：アーキテクチャ（単一のクラス、または小さなコードのいずれか）を提示し、これを現実の世界に転送してみてください。 日常生活でコードのロジックに似たものを見つけてください。 そして、実生活の例に基づいて、1つまたは別のソフトウェアコンポーネント（オブジェクト）の動作方法を理解します。 最終的に結果がどうあるべきかを理解してください。

今回は同じことをします。

プログラミングを中断して、手術室に行きましょう。

人命を救うことは非常に重要な仕事です。 医師チームの各メンバーは、自分の仕事を正確に実行し、他の人が自分の仕事を実行するのを妨げないようにする必要があります。

すべてのツールは棚にきちんと配置されています。 主治医は集中的に手術を行い、定期的に助手に頼ってメスなどの新しい道具を手に入れます。 さまざまな時点で、「異なるメス」が必要になる場合があります。そのため、アシスタントがプロセスの邪魔にならず、現在必要なツールを正確に提供することが重要です。

医師は、自分が必要とするツールがどの棚にあるかを絶対に気にしません。 ミスを防ぐために、彼は業務に完全に集中することがより重要です。これは彼の責任範囲です。

アシスタントは、この操作で必要なすべてのツールの可用性、清潔さ、医師へのツールのタイムリーな提供に責任を負います。 最も興味深いのは、アシスタントが状況に応じて、どのツールを選択するかを独自に決定することです。 もちろん、医師が正確な指示を持っていなかった場合。

私たちの場合、アシスタントはダガーです。 医師は、プログラムで明確な使命を持つ当社のソフトウェアコンポーネントです。 パターン-依存性注入（依存性注入）が存在するのは、依存関係（ツール）の作成とプロビジョニングの委任（医師からアシスタント）にあります。

この例から学べること：

1. コンポーネントには、他のコンポーネントを作成するロジックを含めるべきではありません。
   
   
2. コンポーネントは、そのツールの実装について心配する必要はありません。 この例では、外科医が「メス！」と尋ねると、シチュエーションアシスタントはセットから目的のアシスタントを返します。 T.O. 医師はツールの特定の実装ではなく、それらのインターフェイスで作業していると言えます。

練習。 プログラミングに戻りましょう。

大部分のアプリケーションでは、何らかの種類のデータリストを扱う作業があります。
アダプターはデータ処理を行い、コンストラクターに渡します。

1. リスナー-リスト項目との相互作用のイベント。
2. おそらく、ViewHodlersを作成するためのコンテキストまたはLayoutInflater。
3. もちろん、データリスト自体は、もちろん事前に初期化されていない限り（そうでなければ、アダプターはsetList（）メソッドを実装します）。

しかし、最終的にはどうなりますか？ フラグメント（またはアクティビティ）で構造を受け取った

Adapter adapter = new Adapter(this, getContext(), list); recyclerView.setAdapter(adapter); 

別のコンポーネントを初期化することにより、コンポーネントを処理しました。 医師は手術台から離れて適切なツールを見つけました。



Daggerを使用すると、提示されたコードの最初の行を取り除くだけでなく、別のコンポーネントを作成するロジックから不要なロジックからコンポーネントを解放します。

ちょっと待って、質問がここに表示されることがあります。

アダプターの初期化がDaggerに委任されている場合、彼はどこでリスナー（リスナーを実装するコンポーネントのオブジェクト）を取得しますか？ シングルトンのフラグメントまたはアクティビティを保持することは、悪い考え以上です！

このような質問は、次の場合に発生する可能性があります。

1. アプリケーション全体に対して1つまたは2つのコンポーネントを使用します。
2. すべての依存関係をシングルトンに保ちます。
3. そして、サブコンポーネントとコンポーネントの依存関係について知りたくありません。

ダガーの研究の最初に欠けていた、少し抽象化してみましょう。

Daggerのインターネットでの使用例のほとんどには、コンテキストルート依存関係（または本質的にはコンテキストでもあるアプリケーションを拡張するクラス）を備えたAppModuleを使用したいわゆるAppComponentの作成が必ず含まれます。

理由を理解しましょう。

「最初は言葉でした...」

コンテキストがあると、他の依存関係を取得できます。たとえば、SharedPreferences、LayoutInflater、何らかのシステムサービスなどです。 したがって、SharedPreferencesを持つことで、PreferenceHelperを取得できます。これは、設定を操作するためのユーティリティクラスです。 LayoutInflaterを使用すると、ViewFactoryを取得できます。 これらの「高レベル」依存関係から、さらに複雑で複雑な依存関係を取得することもできます。 そして、この多様性はすべて、1つのオブジェクト、つまりコンテキストに由来していました。 この場合、AppComponentのコアと呼ぶことができます。


そして、上記のすべては、アプリケーション全体、つまり シングルトン。 そのため、私たちが持っているコアは、常に存在するオブジェクト-アプリケーションコンテキストオブジェクトです。

この考えを続けて、アダプターがどれくらいの期間存在するかを考えてみましょう。 明らかに、このアダプタが機能する画面があります。

ViewHolderFactoryをアダプタに提供します。アダプタは、アダプタが存在する限り存在する必要があります。 アダプタに加えて、フラグメントにViewControllerを提供します。フラグメントも存在する場合にのみ存在する必要があります。

見ると、この画面が「生きている」間に排他的に使用されるすべての依存関係は、この画面に依存しています。 T.O. 私たちのフラグメント（またはアクティビティ）は、画面が存在する限り存在するローカルコンポーネント-コンポーネントのコアになると言えます。


依存関係のこのすべてのローカルバンチ（列）に対して明確に定義されたライフタイムを実装するには、サブコンポーネントを使用します。

「どうやって？」と聞いて

とりあえず、サブプレフィックスを忘れて、コンポーネントだけを実装していると想像してみましょう。 簡単な場合は、画面がアプリケーション全体であることを想像してください。

まず、基本的なモジュールが必要です。 なぜなら リスト画面、これをListModuleと呼びます。

 @Module public class ListModule { } 

今、私たちはまさにコア、つまり他の誰もが行く基本的な依存関係を必要としています。 前述のように、ListFragmentなどの「画面オブジェクト」自体は、画面の基本的な依存関係です。 それをモジュールのコンストラクターに渡しましょう。

 @Module public class ListModule { private final ListFragment fragment; public ListModule(ListFragment fragment) { this.fragment = fragment; } } 

基礎、そして創造性があります。

アダプターを提供します。

 @Provides public Adapter provideAdapter(Context context) { return new Adapter(fragment, context, fragment.initList()); } 

注：コンテキストはありますが、明らかに、このモジュールまたはコンポーネントの他のモジュールのいずれにも提供していません。 これについては後で詳しく説明します。

データ自体のリストを個別に提供することもできます（これは冗長ですが、例では機能します）。

 @Provides public List<Model> provideListOfModels() { return fragment.initList(); } @Provides public Adapter provideAdapter(Context context, List<Model> list) { return new Adapter(fragment, context, list); } 

さて、それを正常に機能させるために、いくつかの設定を行います。

ダガーに伝えるために：

1. コンポーネントのすべての依存関係は、メインのグラフとは別の単一のグラフです。
2. 毎回新しい依存関係を作成するのではなく、唯一の依存関係をキャッシュする必要があります。

いわゆるスコープ注釈があります。 各スコープ注釈は次のようになります。

 @Scope @Retention(RetentionPolicy.Runtime) public @interface Singleton {} 

シングルトンは、Daggerが提供する基本的な注釈です。 それはあなたが何かを始めるためだけに提供されています。 「シングルトン」自体は、AppComponent（Appを拡張するクラス）にAppComponentを保存しない限り、魔法のようには発生しません。 すなわち Daggerは、Componentのこのインスタンスに対して依存関係の単一のインスタンスが作成されることを保証します。 ただし、コンポーネントインスタンスの一意性はユーザーの責任です。

同様に、スコープアノテーションを作成します。

 @Scope @Retention(RetentionPolicy.Runtime) public @interface ListScope {} 

私たちの注釈は、Singleton注釈よりも決して劣っていません。全体のポイントは、それらの使用方法です。

スコープ注釈を使用して、提供メソッドとモジュールを含むコンポーネントをマークします。

重要：特定のスコープによって署名された1つのコンポーネントには、同じスコープによって提供メソッドが署名されたモジュールのみが存在できます。 T.O. 2つの異なる依存関係グラフは交差しません。

ListModuleの最終ビュー：

 @Module public class ListModule { private final ListFragment fragment; public ListModule(ListFragment fragment) { this.fragment = fragment; } @ListScope @Provides public List<Model> provideListOfModels() { return fragment.initList(); } @ListScope @Provides public Adapter provideAdapter(Context contex, List<Model> list) { return new Adapter(fragment, context, list); } } 

コンポーネント：

 @ListScope @Subcomponent(modules = ListModule.class) public interface ListComponent { void inject(ListFragment fragment); } 

ここで重要なのは@Subcomponentアノテーションです。 したがって、親コンポーネントのすべての依存関係にアクセスしたいと言いますが、ここでは親を指定しないことに注意してください。 この例では、親はAppComponentです。

* Contextを取得してアダプターを初期化するのはAppComponentからです。

サブコンポーネントを取得するには、サブコンポーネントのすべてのモジュールを引数として渡すことで、親コンポーネントでの受信方法を記述する必要があります（この場合、1つのモジュールのみ）。

それはどのように見えますか：

 @Singleton @Component(modules = AppModule.class) public interface AppComponent { ListComponent listComponent(ListModule listModule); } 

Daggerはこのメソッドの実装を処理します。

人生の時間を整理します

既に述べたように、AppComponentにはその唯一のインスタンスが格納されているため、AppComponentはシングルトンです。 親の助けを借りてのみサブコンポーネントのインスタンスを作成できます。したがって、Appクラスでサブコンポーネントを受信および保存するすべてのロジックを削除しますが、1つの重要な違いがあります：いつでもサブコンポーネントを作成し、いつでも破棄する機能を追加します。

Appクラスでは、次のロジックを記述します。

 public class App extends Application { private ListComponent listComponent; public ListComponent initListComponent(ListFragment fragment) { listComponent = appComponent.listComponent(new ListModule(fragment)); return listComponent } public ListComponent getListComponent() { return listComponent; } public void destroyListComponent() { listComponent = null; } } 

注：大規模なプロジェクトでは、構成を使用してDaggerを操作するロジックをAppクラスからヘルパークラスに移動することは理にかなっています。

さて、フラグメント内でこれらすべてを使用することを説明することは残っています。

 public class ListFragment extends Fragment { @Inject Adapter adapter; @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); App.getInstance().initListComponent(this).inject(this); init(); } private void init() { recyclerView.setAdapter(adapter); } @Override public void onDestroy() { super.onDestroy(); App.getInstance.destroyListComponent(); } } 

したがって、グラフのライフタイムをフラグメントのライフサイクルにリンクしました。

これは、1つの依存関係の場合には冗長に見えるかもしれません（1つの依存関係があったとしても、そのようなロジックを取り除くとコードがよりきれいになり、 フックが少なくなります ）。 ほとんどの作業は、アーキテクチャを作成することです。 したがって、新しい依存関係を提供する必要がある場合、1つの提供メソッドの実装になります。

ボーナス

すべての依存関係が提供メソッドで強調表示されている場合、依存関係をスローするのをやめるなどの素晴らしいことがあります。 アダプターを使用した例を再度検討してください。

ListFragmentは、リストオブジェクトのViewHoldersに関連するイベントのリスナーを実装します。 したがって、各ViewHolderにリスナーを配信するには、アダプターへのリスナーへのリンクを保存する必要があります。

仲介者を取り除きます。



ViewHolderFactoryでViewHoldersの作成を削除することをお勧めします。 だから私たちはやる：

 public class ListItemViewHolderFactory { private final Listener listener; private final LayoutInflater layoutInflater; public ListItemViewHolderFactory(LayoutInflater layoutInflater, Listener listener) { this.layoutInflater = layoutInflater; this.listener = listener; } public ListItemViewHolder createViewHolder(ViewGroup parent) { View view = layoutInflater.inflate(R.layout.item, parent, false); return new ListItemViewHolder(view, listener); } } 

モジュールは次の形式に変換されます。

 @Module public class ListModule { private final ListFragment fragment; public ListModule(ListFragment fragment) { this.fragment = fragment; } @ListScope @Provides public List<Model> provideListOfModels() { return fragment.initList(); } @ListScope @Provides public Adapter provideAdapter(ListItemViewHolderFactory factory, Context context, List<Model> list) { return new Adapter(factory, context, list); } @ListScope @Provides public ListItemViewHolderFactory provideVhFactory(LayoutInflater layoutInflater) { return new ListItemViewHolderFactory (layoutInflater, fragment); } } 

注：AppModuleでLayoutInflaterを提供することを忘れないでください。

この例は、依存関係の柔軟な作業がいかにうまくいくかを示しているように思えます。

次に、特定のコンポーネント（クラス）のコードレビューを行い、そのロジックのみを表示する世界を想像してください。 イベントのスレッドを追跡するために、ソフトウェアコンポーネント間で「ジャンプ」する必要はありません。 外部ツールは自分で表示され、インターフェイスを介して他のコンポーネントとやり取りします（またはまったくやり取りしません）。


この記事があなたに思考と創造性の土台を与えてくれて、ダガーの世界が少しでも近づいたことを願っています。

次回は、アシスタントの機能の2番目の部分を分析します。状況に応じて、「メス」の特定の実装を返します。 認可されたゾーンとソーシャルネットワークでの作業について話しましょう。

ご清聴ありがとうございました。

githubの記事に記載されている例。

UPD： パート2