すべてのメソッドが仮想ではないのか、各クラスに少なくとも1つのインターフェイスがないのはなぜですか？

これは.NETプラットフォームに関するより哲学的な質問ですが、他の言語でも役立つかもしれません。私は多くの単体テストを行っていますが、特に私がしばしば苦労しているサードパーティのコンポーネントを使用している場合はそうです。.NETでは、コンポーネントの設計者に、どのメソッドを仮想化するかどうかを選択するという大きな主張があります。1つはコンポーネントの使用方法（仮想化する意味がある）、もう1つはコンポーネントのモック機能です。Shimsを使用してサードパーティのコンポーネントをモックアップできますが、これは多くの場合、設計や複雑さを悪化させます。.NETでのすべてのメソッドの仮想化（JAVAには最初からあります）についての議論は、パフォーマンスに関するものでした。しかし、それはまだ問題ですか？なぜすべてのメソッドが.NET virtualではないのか、または各クラスに少なくとも1つのインターフェイスがないのはなぜですか？

Andersが言うように、その一部はパフォーマンスについて、一部は不十分に考えられたデザインをロックダウンして、継承するように設計されていないものを盲目的に継承する人々によって引き起こされるトラブルの範囲を減らすことです。

パフォーマンスは明らかなようです。ほとんどのメソッドは最新のハードウェアでは認識されませんが、仮想パイプラインゲッターは、CPUパイプラインで予測しやすい命令にますます依存する最新のハードウェアであっても、かなりのヒットを引き起こす可能性があります。

現在、すべてをデフォルトで仮想化する理由は、単体テストフレームワークという1つの要素のみによって推進されているようです。これは、フレームワークを適切に設計するのではなく、フレームワークに合うようにコードを変更するのは悪い理由だと私には思えます。

おそらく問題はここで使用されているフレームワークにあります。これらは、実行時にコードを構築するのではなく、シムを挿入して実行時に関数を置き換えることができるように改善する必要があります静的およびサードパーティの機能について言及する）

したがって、メソッドがデフォルトで仮想ではない理由は、Andersが述べたとおりであり、ユニットテストツールに合うように仮想化したいという希望は、カートを馬の前に置くことです。

これで、インターフェースを使用するか、コードベース全体を作り直して、直接有線のメソッド呼び出しではなくメッセージパッシングを介して通信するコンポーネント（またはマイクロサービス）を使用することで、これらすべてを軽減できます。テストのためにユニットの表面を拡大してコンポーネントにし、そのコンポーネントが完全に自己完結型である場合、それを単体テストするために実際にねじ込む必要はありません。

質問には2つの要素があるので、順番に説明していきます。

1. .NETメソッドがデフォルトで仮想化されないのはなぜですか？

   継承には、実際には多くの問題があります。したがって、デザインの一部として使用する場合は、慎重に検討する必要があります。メソッドをデフォルトで非仮想化することにより、クラスを設計するときに開発者が継承について考えることを奨励するという理論があります。それが実際に機能するかどうかはもちろん別の問題です。

2. すべてのクラスがインターフェースを実装しないのはなぜですか？

   貧弱なデザインは簡単な答えです。非常に長い間、優れた実践として一般に認識されているにもかかわらず、悲しいことに多くの人々はDIとTDDを考慮してシステムを設計していません。

完全に継承可能ではなく、簡単にモック化されないクラスの組み合わせは、テストが難しいコードの「完全な嵐」を作り出します。誰もがDIとデザインからインターフェースへの原則を使用する日がくるまで、痛みを軽減するためにできることはあまりありません。