単純なクラスでメソッドをスタブ化したいときはいつでも、ほとんどの場合、インターフェイスを抽出します。そのクラスのコンストラクターがパブリックであり、複雑すぎたり複雑な型に依存したりしていない場合は、問題のメソッドを仮想化して継承するだけで同じ効果があります。これは、インターフェイスを抽出するよりも望ましいですか? もしそうなら、なぜですか？
編集：
class Parser
{
public IDictionary<string, int> DoLengthyParseTask(Stream s)
{
// is slow even with using memory stream
}
}
2 つの方法があります。インターフェイスを抽出するか、メソッドを仮想化します。IParser Parser私は実際にはインターフェースを好みますが、それはタプルの爆発につながる可能性があります...
単体テスト以外で何を達成しようとしているのかを考慮する必要があります。ツールにデザインを指示させないでください。
インターフェイスを扱うことでコードを切り離すことができますが、これらはコード内の自然な分離ポイントでなければなりません (ビジネス ロジックやデータ アクセスなど)。これらのメソッドを継承して上書きする場合、メソッドを仮想化することは理にかなっています。
あなたの場合、メソッドではなく、使用する動作を直接テストしようとします。DoLengthyParseTaskこれにより、より堅牢なテスト スイートも提供されます。このメソッドを本当にパブリックにする必要があるかどうかを慎重に検討する必要があります(つまり、独自のアセンブリの外部で参照でき、参照する必要があります)。
インターフェースは、基本的には、実装が指定された一連の接点 (メソッド、プロパティなど) へのアクセスを提供することを約束するだけであり、動作の仕様はありません。約束を守る限り、何をしても自由です。
一方、基本クラスは、コントラクトに加えて、クラスでコード化されている少なくともいくつかの動作を指定します (すべてが抽象的でない限り、それは別の話です)。メソッドを仮想化しても、ベースの実装で呼び出すことができ、それとともに独自のコードを提供することもできます。
この動作の継承は基本的に、現在の OOP で多重継承が禁止されている理由であり、複数のインターフェイスの実装は比較的一般的です。
とはいえ、コントラクトを抽出したいだけなのか、何らかの動作も抽出したいのかを重み付けする必要があり、その答えは特定のケースでは明らかです。
IParser/ペアについてはParser、第一に単体テストと依存性注入に最適であり、第二に、クラスの作成に課金されないため、必要なだけ自由に作成してください。
インターフェースにプログラミングすることで、単体テストでのモック/スタブ化と疎結合コードの容易さ (そしてその結果、はるかに高い柔軟性) の利点を、文字通り無料で得ることができます(唯一の欠点は、管理するアーティファクトが増えることです)。
インターフェイスと継承は 2 つの別個のものであり、それらを同じ意味で使用することは可能ではありますが、お勧めできません。メソッドをマークすることで、本質的には、実装でこのメソッドを自由に変更virtual(オーバーライド) できることを他の人に伝えているだけでなく、実際にそうすることが期待されている(そしてあなたは?) ことを伝えています。
このような設計にはかなり重い結果が伴うため、明示的に必要でない限り、使用しないでください。代わりに、インターフェイスへのプログラミングに固執してみてください。
優れたオブジェクト指向設計原則の 1 つは、インターフェースに合わせてプログラミングし (コントラクトによる設計、Liskov Substitution Principle )、継承よりも合成を優先する(クラスはインターフェース/抽象クラスを実装するだけでなく、そのような実装で構成する必要がある) と述べています。
あなたのParser例は、抽象化の背後に隠されるのに最適な候補になっていることに注意してください（インターフェイスまたは基本クラス）。コンシューマーの観点からは、データがどのように作成されるかは問題ではありません。今のところ、XML ストリームのみと考えるかもしれませんが、要件は変化 (および/または増加) する傾向があり、すぐにバイナリ ファイル パーサーを実装していることに気付くかもしれません。データ ストリーム マイニング パーサーと what-not-else。今すぐ適切に実行して、後で時間と手間を省いてください。