拡張メソッドを使用すると、メソッドを任意の型に簡単に追加できます。明らかに、これにより、.net の将来のバージョンで、拡張メソッドが呼び出されなくなる可能性が開かれます (たとえば、タイプには、拡張メソッドと同一のシグネチャを持つメソッドが含まれるようになりました)。
これは心配する必要がありますか?
もしそうなら、これにどのように対処し、これが発生した場合にコードの変更を最小限に抑えるように拡張メソッドを設計する必要がありますか?
拡張メソッドを使用すると、メソッドを任意の型に簡単に追加できます。明らかに、これにより、.net の将来のバージョンで、拡張メソッドが呼び出されなくなる可能性が開かれます (たとえば、タイプには、拡張メソッドと同一のシグネチャを持つメソッドが含まれるようになりました)。
これは心配する必要がありますか?
もしそうなら、これにどのように対処し、これが発生した場合にコードの変更を最小限に抑えるように拡張メソッドを設計する必要がありますか?
フレームワークが将来大幅に変更された場合、常に互換性の問題が発生します。新しいフレームワーク メソッドが拡張メソッドと同じ名前で追加された場合、同じか、少なくとも非常に類似した機能を持つ可能性が非常に高く、とにかくリファクタリングが必要です。
このリスクがあるからといって、拡張メソッドの力が大きすぎて無視できないと思います。
フレームワークで使用されることのないあいまいなメソッド名を使用します。
編集-- おそらくあいまいという言葉は適切ではありませんでした。意味のある、しかしあまり一般的ではない言葉に置き換えてください
署名の競合を回避しようとすることは、コードのやり直しの煩わしさを回避するための唯一の戦略です (拡張メソッドの機能を保持する必要があり、単にフレームワークのメソッド定義に変換するのではないと仮定します)。
残念ながら、あなたができる唯一のことは、拡張メソッドに十分に一意の名前を付けることです。これにより、競合が発生しないことを 100% 確信できます。
猫の名前をメソッドの名前に追加することについて話しているのではなく、もっと創造的になるようにしてください:)