私は既存のアプリケーションで使用されるJavaライブラリを作成しています。私は依存性注入を使用しているので、テストは簡単です。私はSpringに精通していますので、テスト中に依存性注入を管理するために使用する予定でした。最終的にライブラリを使用するアプリケーションは、Springベースではなく、現在どのようなIoC/DIコンテナも使用していません。私の質問は、SpringやGuiceが使われていない場合に、依存関係を注入するための最良の方法は何でしょうか？オブジェクトをインスタンス化しワイヤリングするためのファクトリメソッドのようなものを検討する必要がありますか？依存関係はすべてライブラリ内にあるため、アプリケーションに各依存関係をインスタンス化してメインオブジェクトを作成させるのは適切ではないようです。ライブラリでの依存性注入の使用
SpringまたはGuiceが使用されていない場合、依存関係を注入するための最良のアプローチは何ですか？
あなたのライブラリがDIに優しいイディオムで書かれている場合。ひどいjava APIとして使用するのはかなり簡単です。あなたの過去の春の経験を考えてみましょう。そこには、春のモデルに完全に適合するが、春の前に書かれたライブラリがいくつかあります。私はnewで何も悪いことがありませんが、setXXの後に実際の仕事メソッドが呼び出されます。他のものの中でも、あなたのクライアントは信頼性の高い方法で呼び出されるinitメソッドを呼び出すことを忘れることがあるので、特に注意してください。
オブジェクトをインスタンス化しワイヤリングするためのファクトリメソッドのようなものを考慮する必要がありますか？依存関係はすべてライブラリ内にあるため、アプリケーションに各依存関係をインスタンス化してメインオブジェクトを作成させるのは適切ではないようです。
クライアントアプリケーションに決定させます。あなたは図書館を提供しています。 APIクライアントに独自のオブジェクトを配線させます。例を挙げてください。後で、同じ例を使用して、クライアントのドメインでファクトリメソッドを作成することができます。たぶん、クライアントアプリケーション自体が自分自身を構成する方法を持っていて、あなたのライブラリがそれを利用するのに十分な柔軟性を備えていれば望ましいでしょう。
guiceを含めることもできます。ライセンスはApacheです。 Java全体のようなもの。