3

職場の開発者の 1 人が、DI の要点はインターフェイスの使用にあると述べているのを聞きました。経験則として、具象クラスの使用は最小限に抑える必要があります。特定のクラスを使用するように DI を構成するインスタンスがいくつかある場合、それはコードのにおいです。

これを無条件のルールとして受け入れることができるかどうかはわかりません。私がいつも感じていた DI の大きな理由の 1 つは、テストの容易さです。

私のコードの依存関係として具体的なクラスを介してインターフェイスを使用する他の理由があるかもしれません（ロジックの他の実装を簡単にプラグインするなど）が、依存性注入の使用がそれをどのように意味するかわかりません。

編集: 予約オブジェクトをあるドメインから別のドメインにマップするクラス BookingMapper があるとします。Booking のマッピングの一部としてマッピングする必要がある Hotel オブジェクトがあるとします。これは HotelMapper クラスを使用して同じことを行います。

public class Booking
{
    ...
    Hotel Hotel;
}

public class BookingMapper
{
    private readonly HotelMapper hotelMapper;
    public BookingMapper(HotelMapper hotelMapper)
     {
      this.hotelMapper = hotelMapper;
     }
    Map(){...}
}
public class HotelMapper
{
     Map(){...}
}

このようなユースケースでは、Booking Mapper コンポーネントがすべての点で HotelMapper と同じレベルにあり、単一責任の原則により分離されていることは既にわかっています。次のようなインターフェースを抽出することはまだ意味がありますか

public interface IHotelMapper
{
void Map();
}
public class BookingMapper
    {
        private readonly IHotelMapper hotelMapper;
        public BookingMapper(IHotelMapper hotelMapper)
         {
          this.hotelMapper = hotelMapper;
         }
        Map(){...}
    }

次に、HotelMapper を直接使用するよりも、BookingMapper の依存関係として使用しますか?

4

2 に答える 2

1

依存性注入は、インターフェースを定義せずにそれ自体で完全に使用できるパターンです。コンシューマを他の具象クラスに依存させることができます。これらのクラスの重要なメソッドを仮想化することで、テスト目的で偽の実装を派生させることさえできます。

ただし、実装ではなく抽象化に依存する場合、多くの利点があります。

  • 実際の実装を後回しにする必要がないため、テストがはるかに簡単かつ安全になります。
  • コンシューマは実装ではなく抽象化のみに依存するため、アプリケーションの一部を個別にデプロイできます。
  • デコレーター パターンを使用して(または、 interceptionなどの他のAOP手法を使用して)動作を追加すると、インターフェイスを処理するときにはるかに簡単になります。
于 2013-06-25T19:33:28.413 に答える