Google Guiceについて読み、依存性注入に対する他のアプローチの一般的な問題を理解しましたが、Guiceを「実際に」使用してその価値が明らかになる例はまだ見ていません。
誰かがそのような例を知っているのだろうか?
Google Guiceを使用して単体テストを容易にすることは、高レベルの利点にすぎません。プロジェクトでユニットテストを使用しない人もいるかもしれません。人々は、単体テストだけでなく、Spring/DependencyInjectionを使用しています。
Google Guiceを使用することの低レベルの利点は、アプリケーションの結束の問題です。プロジェクトのクラスは、相互に疎結合できます。相互に依存することなく、別のクラスにクラスを提供できます。
この例を考えてみましょう。
public class A{
}
public class B{
A a = new A();
}
クラスBはクラスAと緊密に結合されます。つまり、クラスAの存在に依存します。
しかし、Guiceを使用すると、代わりに次のように疎結合にすることができます。
public class B{
private A a;
@Inject
public B(A a){
this.a = a;
}
}
クラスBはAに疎結合され、Bがインスタンス化する代わりに、GuiceがAのインスタンスを提供する責任があります。これにより、AからBへのインターフェースを提供するように拡張でき、アプリを単体テストする場合は、実装をモックオブジェクトにすることができます。
ここまでは、依存性注入の利点についてのみ説明していると述べました。依存性注入を超えて、GoogleGuiceを使用する利点は次のとおりです。
それがその概要です。しかし、Guiceを深く理解するにつれて、Guiceには多くの優れた点があります。 simpleの実際の例は、 MVP実装でGWT を使用している場合、GWTアプリケーションのコンポーネント/ウィジェットは非常に疎結合であり、互いに緊密に統合されていません。
たぶん、時間をさかのぼって、Guiceが解決したかった問題を詳しく調べる必要があります。 Guiceの背後にある動機を理解するには、 Bob Lee:I Do n't Get Spring TheServerSide.COMのニュース(およびそのコメント)が完璧な出発点です。次に、 Google Guice、A Java Dependency Injection Framework (およびコメント)の発表と Tech Talk:Googleのボブリー)に進みます。 Guice (およびコメント)。
個人的に、私は邪悪なXMLについての懸念を共有していました:XML構成の地獄、XMLと起こりうるランタイムエラー、エラーが発生しやすい、リファクタリングが悪い文字列識別子など。実際、Springと同意についての懐疑的な意見は誰にとっても良かったと思います(春を含む)。したがって、DIフレームワークランドスケープの新しいプレーヤー、特にJava 5つの機能(タイプセーフのためのジェネリックスとアノテーション))を活用する最新のフレームワークを見てうれしくなりました。
また、GoogleはミッションクリティカルなアプリケーションでGuiceを実行しているため(ほとんどすべてのJavaベースのアプリケーションはGuiceベースのアプリケーションでもあります:AdWords、Google Docs、Gmail、そして、「クレイジー」ボブ・リーが Guice² )で報告したYouTubeでさえ、Guiceが完全に間違っていて、何の価値も提供していないとは信じられません。悲しいことに、Googleがこれらのアプリケーションのコードを例として提供することはないと思います...しかし、 Guiceを使用するアプリケーションのリスト または リストサードパーティのGuiceアドオンの 。または Guice² で言及されている本をチェックしてください。またはボブに聞いてください:)
利点は、インターフェース、テスト、およびプロキシへのコーディングにあると思います。
インターフェイスにコーディングすると、コードを適切に階層化でき、テスト用のモックを注入でき、プロキシを自動的に生成できるため、クライアントコードは実装について心配する必要がありません。
これは、Guice、Spring、PicoContainer、およびすべてのDIフレームワークに当てはまります。
十分に簡潔ですか?