完全に単体テストされたいくつかの便利なユーティリティ メソッドを含む小さなユーティリティ ライブラリがあります。現時点では、私のライブラリには外部依存関係はありません。デバッグの目的で役立つ可能性のあるログをクラスに追加するというアイデアをいじっています。しかし、これは私のプロジェクトにログ ライブラリをバンドルすることを意味します。
私の質問は、ライブラリの依存関係をなくす必要がありますか? そうすることの利点はありますか？
4 に答える
5
ロギングを抽象化するために使用できるロギングインターフェイスを追加します。次に、ユーザーがこのインターフェイスを介してログを追加できるようにします。あなたもこのインターフェースを使用する必要があり、他のロギングが必要ない場合に使用されるライブラリに組み込まれた「NullLogger」を提供する必要があります。
構成ファイルまたは実行時検出によって、ユーザーに新しい構成を要求することにより、NullLoggerを使用しないようにすることが簡単にできます。
于 2010-10-26T07:55:02.793 に答える
1
そうすることには多くの利点がありますが、ほとんどのオペレーティングシステムで実行できることも重要です。
ライブラリをかなり依存関係のない状態に保つ1つの方法は、使用する前にライブラリを初期化することを要求することです。次に、your_lib_init（）;を実行します。関数は、ロギングバックエンドへの関数ポインタを取ります。つまり、バックエンドは、実行される可能性のある任意のプラットフォーム用に書き直すことができます。
また、すべてのライブラリ依存関係がないライブラリ、または標準のクラスパスに依存するライブラリが必要かどうかも判断してください。純粋なJavaの場合は、J2ME、Android、GCJを使用したネイティブコンパイル済みJavaなどで実行されます。クラスパスを使用する場合、実際には、OpenJDKが実行される場所であればどこでも、すべてのクラスパス実装間で移植可能になります。
于 2010-10-26T07:54:43.117 に答える
0
プロ：
- ライブラリははるかに小さくなります（依存関係の全機能のごく一部しか使用していない可能性があります）
- 更新地獄はありません（コードにライブラリCバージョン2が必要なように、製品XにはコードとライブラリCバージョン1が必要です）。
- 他の誰かの気まぐれにスプーンを曲げる必要はありません（たとえば、1.xから2.xに移行するライブラリ->コードを更新する必要があります）
短所：
- 製品Xにもライブラリが必要な場合の無駄なコード
- あなたはどれくらい賢いですか？図書館にすでに入っている考え、知恵、時間に合わせることができない可能性があります。
PS：ロギングをサポートしたい場合は、コードにslf4jを追加してください。これは30KiBAPIであり、コードのユーザーがそこにある任意のロギングフレームワークを使用できるようにします。commons-loggingを使用しないでください。
于 2010-10-26T08:00:24.803 に答える