インターフェイスを使用する場合（ユニットテスト、IoC？）

私はここで男子学生の間違いを犯したのではないかと疑い、明確化を求めています。私のソリューションの多くのクラス（C＃）-あえて過半数を言う-私は対応するインターフェースを書くことになりました。たとえば、「ICalculator」インターフェースと、それを実装する「Calculator」クラス。ただし、その計算機を別の実装に置き換えることは決してないでしょう。また、これらのクラスのほとんどは、依存関係と同じプロジェクトに存在します。実際に必要なのはinternal、必要なだけですが、publicそれぞれのインターフェイスを実装する副作用として存在することになりました。

すべてのインターフェイスを作成するこのプラクティスは、いくつかの偽りに起因すると思います。

1）元々、ユニットテストモックを作成するにはインターフェイスが必要だと思っていました（私はMoqを使用しています）が、その後、そのメンバーがvirtualであり、パラメーターのないコンストラクターがある場合、クラスをモックできることがわかりました（私が間違っている）。

2）IoCフレームワーク（Castle Windsor）にクラスを登録するにはインターフェースが必要だと当初考えていました。例えば

Container.Register(Component.For<ICalculator>().ImplementedBy<Calculator>()...

実際、私はそれ自体に対して具体的な型を登録することができました：

Container.Register(Component.For<Calculator>().ImplementedBy<Calculator>()...

3）依存性注入のコンストラクタパラメーターなどのインターフェイスを使用すると、「疎結合」になります。

それで、私はインターフェースに夢中になりましたか？！私は、あなたが「通常」インターフェースを使用するシナリオを知っています。例えば、パブリックAPIを公開したり、「プラグイン可能な」機能のようなもののために。私のソリューションには、そのようなユースケースに適合する少数のクラスがありますが、他のすべてのインターフェースは不要であり、削除する必要があるのでしょうか？上記の3）に関して、これを行う場合、「疎結合」に違反しませんか？

編集：-Moqで遊んでいるだけであり、それらをモックできるようにするには、メソッドがパブリックで仮想であり、パブリックのパラメータレスコンストラクターを必要とするようです。それで、私は内部クラスを持つことができないように見えますか？

一般に、実装者が1人だけのインターフェースを作成する場合は、2回書くだけで時間を無駄にします。インターフェースだけでは、1つの実装に密接に結合している場合、疎結合を提供しません。コード。

ただし、ほぼすべてのクラスにインターフェイスがある場合は、少しコードが臭いだと思います。それは、彼らがほぼすべて何らかの形で互いに協力し合っていることを意味します。クラスが多すぎる（ヘルパークラスがないため）か、抽象化しすぎているのではないかと思われます（ああ、重力のためのプロバイダーインターフェイスが変更される可能性があるためです！）。

1）具象クラスがモック可能であっても、メンバーvirtualを作成し、パラメーターを持たないコンストラクターを提供する必要があります。あなた（または新しいチームメンバー）はvirtual、「それが物事の仕組みだ」という理由だけで、何も考えずに、すべての新しいクラスにの、およびパラメーターなしのコンストラクターを体系的に追加することにすぐに気付くでしょう。

依存関係をモックする必要がある場合、インターフェースはIMOよりも優れたアイデアです。なぜなら、インターフェースは本当に必要なときまで実装を延期でき、依存関係の明確で明確な契約を可能にするからです。

3）それは偽りですか？

インターフェイスは、コラボレーションするオブジェクト間のメッセージングプロトコルを定義するのに最適だと思います。たとえば、ドメインエンティティのように、それらの必要性が議論の余地がある場合があります。ただし、通信する必要がある安定したパートナー（つまり、一時参照ではなく注入された依存関係）がある場合は、通常、インターフェイスの使用を検討する必要があります。

IoCのアイデアは、具象型を置き換え可能にすることです。そのため、（現在）ICalculatorを実装する計算機が1つしかない場合でも、2番目の実装は、計算機からの実装の詳細ではなく、インターフェイスのみに依存する可能性があります。

したがって、IoC-Container登録の最初のバージョンは正しいものであり、今後使用する必要があります。

クラスをパブリックまたは内部にすると、実際には関係がなくなり、どちらもmoq-ingになりません。

プロジェクト全体のすべてのタイプについて「モック」する必要性を感じているように見えるという事実について、私は本当にもっと心配しています。

テストダブルは、コードを外部の世界（サードパーティのライブラリ、ディスクIO、ネットワークIOなど）または非常に高価な計算から分離するのに役立ちます。分離フレームワークに寛大すぎる（本当に必要ですか？プロジェクトは複雑ですか？）実装に結び付けられたテストを簡単に導き、設計をより厳格にします。いくつかのクラスがメソッドXおよびYをこの順序で呼び出し、パラメーターa、b、cをメソッドZに渡すことを確認する一連のテストを作成すると、本当に値を取得できますか？ロギングまたはサードパーティのライブラリとの相互作用をテストするときに、このようなテストを取得する場合がありますが、これは例外であり、ルールではありません。

分離フレームワークから、何かを公開する必要があり、常にパラメーターレスコンストラクターが必要であると通知されたら、この時点でフレームワークが悪い（より悪い）コードを書くことを強制しているため、回避する必要があります。

インターフェースについてより具体的に言えば、いくつかの重要な場合に役立つと思います。

• メソッドの呼び出しを異なるタイプにディスパッチする必要がある場合、たとえば複数の実装がある場合（ほとんどの言語のインターフェイスの定義は仮想メソッドのコレクションであるため、これは明らかです）

• 残りのコードを何らかのクラスから分離できるようにする必要がある場合。これは、アプリケーションのコアロジックからファイルシステムとネットワークアクセス、データベースなどを抽象化する通常の方法です。

• アプリケーションの境界を保護するために制御の反転が必要な場合。これは、依存関係を管理するための最も強力な方法の1つです。高レベルのモジュールと低レベルのモジュールはお互いを知らないはずです。なぜなら、それらはさまざまな理由で変化し、ドメインモデルのHttpContextやマトリックス乗算ライブラリのPdfレンダリングフレームワークに依存したくないからです。 。境界クラスにインターフェイスを実装すると（たとえ置き換えられなくても）、レイヤー間の結合を緩めることができ、他の多くのタイプを知っているタイプからレイヤーを介して依存関係が浸透するリスクが大幅に減少します。

私は、一部のロジックがプライベートである場合、そのロジックの実装は誰にとっても重要ではなく、したがってテストされるべきではないという考えに傾いています。いくつかのロジックがテストするほど複雑な場合、そのロジックはおそらく明確な役割を持っているため、パブリックにする必要があります。たとえば、プライベートヘルパーメソッドでコードを抽出すると、通常は別のパブリッククラス（フォーマッター、パーサー、マッパーなど）に配置できるものであることがわかります。
インターフェイスについては、クラスをスタブまたはモックする必要性に駆られました。リポジトリのようなもの、私は通常、スタブまたはモックできるようにしたい。統合テストのマッパー（通常）それほど多くはありません。