適切なクラス構成：複数のハード依存関係を使用

Question

大規模なクラス（2000+行）をより小さい凝集クラス（約200行）にリファクタリングすることで、Javaコードに単一責任原則を統合しようとしています。しかし、の特定のクラスは、newキーワードで複数の "ハード依存関係"を作成するように見えるので、クラス間の結合を適切に減らす方法が混乱しています。

Iは、パラメータとして、依存関係を受け入れ、それが（メソッド本体内の他のロジックをamonstない単純なthis.val = val;セッター使用セッターメソッド、または方法に続いて、主コンストラクタを介して依存性注入を使用している。

IntelliJの自動リファクタリングは、この新しく抽出されたクラスをインスタンス化し、thisの参照をLoadControllerに渡します（注入する）。私が2000ラインクラスをリファクタリングする必要がある場合、もちろん、この自動インスタンス化+次のLoadControllerは、さまざまな機能の開始点として機能する、プログラムのメインステージ用のJavaFXコントローラクラスです。

public class LoadController{ 
     private final DBConnection dbConnection = new DBConnection(this); 
     private final UpdateLabels updateLabels = new UpdateLabels(this); 
     private final OpenCloseMenu openCloseMenu= new OpenCloseMenu (this); 
     private final CreateVBox createVBox= new CreateVBox (this, dbConnection); 
     private final ... 
     private final ... 
} 

これは間違っていますか？私の理解では、大きな独立した関数はそれぞれのクラスになければなりません...しかし、いくつかのクラスは、他のさまざまなクラスの使用の間のロジックの流れを「ガイド」するために、上記のような複数のハード依存関係を持たなければなりません。

Answer 1

JavaFXコントローラへの依存性注入を行う場合は、Gluon Igniteのようなものを使用してください。

Gluon Igniteを使用すると、開発者はFXMLコントローラの内部を含め、JavaFXアプリケーションで一般的な依存性注入フレームワークを使用できます。いくつかの人気の依存性​​の注入は

をフレームワーク上グルーオンのIgniteは、共通の抽象化を作成します（たとえば、Guiceのか春）を使用することを選択した注入フレームワークは、（例えば、あなたがnewを起動していない）注射用のコンポーネントを作成するための責任があると注入しますあなたのコードへの関連参照（例えば、dbConnection = <some value>を書く必要はありません）。注射フレームワークには、それがどのように機能し、どのように使用するのがよいかについての豊富なドキュメンテーションとブログの記事があります。そのための完全な議論はこの答えの範囲外です。

グルーオンのIgniteへの代替似ていますが、@Injectための小さなカスタム実装を使用するため、より軽量である（そして少し強力）は、afterburner.fxである、（ただし、使用することは非常にシンプルな）その後、より確立された依存性注入フレームワーク。

これは単なる1つの選択肢ですが、これに対処できる他の方法もありますが、JavaFXで依存関係注入を実行することを望んでいると、ロールを張ろうとするよりもむしろ実証済みのフレームワークを理解できるようですあなた自身の実装。

いくつかのクラスは、他のさまざまなクラスの使用の間のロジックの流れを「ガイド」するために、上記のような複数のハード依存関係を持たなければなりません。

Guiceのようなものを使用して、インターフェイスタイプと実装の間のバインディングを定義するモジュールを提供します。これらのバインディングは、Guiceに依存関係を構築する方法を伝えるので、クラス内の依存関係をハードコードする必要はありません。モジュールの例については、Guice getting started guideのBillingModuleを参照してください。注射可能なオブジェクトの複数のインスタンスが必要な場合は、GuiceにProvidersを使用できます。 Springにも同様の概念がありますが、名前は異なります。依存性注入フレームワークを使用するかどうかの決定

---

は、あなたのアプリケーションにフレームワークを統合する追加の時間と複​​雑対何の注入フレームワークがなかった場合の対処が必要となる作業の間のトレードオフです。そのため、使用するかどうかの決定は、建築上の決定でなければなりません。そのようなフレームワークの使用が正当であるかどうかについて、あらゆるアプリケーションに対して一般的な正誤の答えはありません。

私は、注入フレームワークを使用することが自分の要件に余計であると判断しましたが、上に示したように、いくつかのクラスに複数の依存関係を持つことによって、

まあ、依存関係はどこかで定義する必要があります。従来のresponsibility driven design approachから判断してもよいように、依存注入システムなどの推論された場所や集中した場所では、指定されたクラスを使用したりローカルで使用したりします。したがって、ハード依存関係を持つことによって、間違ったことをする必要はありません。依存性注入などの抽象的なデカップリングパターンは必ずしも必要ではありません。

このトリックは、どこでどのような依存関係を管理するかを決定することです。しばしば、明らかに問題ドメインから自然に逸脱し、時にはCRC modelingなどのテクニックが構造依存性を助けることがあります。

関連記事：

• Inversion of Control Containers and the Dependency Injection pattern by Martin Fowler。

私の仮定は、私は新しいを使用して、複数のハード依存関係を持つこれらのクラスの一部と小さく、凝集のクラスに私の大きなクラスをリファクタリングすることができますということです。

はい、確かにそうすることができます。

注入フレームワークは、後でプロジェクトの生涯で統合することはできますか？

はいできます。そうすることは少しの作業ですが、アプリケーションがうまく構成されていれば、それほど難しいことではありません。他の方法に進んで、すでに依存しているアプリケーションやライブラリから依存関係注入フレームワークの使用を取り除こうとするのは、より困難です。

関連：

• Passing Parameters JavaFX FXML