8

私が見たすべての DI の例では、依存関係をサービスなどの他のクラスとして常に見ています。ただし、オブジェクトは、文字列やリソース ラッパー (大きな値の文字列/ドキュメント全体やリーダーではなく、ファイル/パス/URI/URL) などの構成値に大きく依存している場合があります。

これは、Java または C# 構文のみの DI 設計パターンに関するものであり、特定の DI フレームワークがこれを処理する方法ではないことに注意してください。

たとえば、文字列 (あいまいな実装ロジックに基づく相対パス) を返すこのクラスがあるとします。ユーザーは自分のマシンにさまざまなプロジェクトを持つことができ、このクラスは呼び出されるたびに特定のプロジェクトに基づいてロジックを実行するため、(さまざまな実装者ではなく) "projectLocation" に構成/初期化の依存関係があります。

public abstract class PathResolver {

    protected File projectFilesLocation;

    public RoutinePathResolver(File projectFilesLocation) {
        this.projectFilesLocation = projectFilesLocation;
    }

    public abstract String getPath(String someValue);
}

私は単体テストのためだけにDIを使用していません（私は単体テストでもなく、既存のプロジェクトでもありません）。依存関係/作成に関する懸念とロジックに関する懸念の期間を分けたいだけです。

4

1 に答える 1

3

ファイルの場所など、注入したいものがクラスによって直接使用されるものであれば、それを注入することは完全に有効です。

aや aObjectなどの場合、これは Service と呼ばれるものと同じです。これはクラスの依存関係であるため、DI が適用されます。FileString

于 2013-03-21T12:14:33.180 に答える