インターフェースとバージョン管理

Question

新しいシステムを設計しており、システムの時間の経過とともに増加するインターフェイスが多数あります。このインターフェイスに名前を付けるベスト プラクティスは何ですか?

ISomethingV01
ISomethingV02
etc

そして私はこれをします

public interface ISomething{
      void method();
}

次に、方法 2 を追加する必要があるので、どうすればよいでしょうか?

public interface ISomethingV2:ISomething{
      void method2();
}

それとも別の方法でも同じですか？

Answer 1

理想的には、インターフェイスを (たとえ変更するとしても) 頻繁に変更すべきではありません。インターフェイスを変更する必要がある場合は、その目的を再考し、元の名前が引き続きそのインターフェイスに適用されるかどうかを確認する必要があります。

それでもインターフェイスが変更されると思われ、インターフェイスの変更が小さく (項目の追加)、コード ベース全体を制御できる場合は、インターフェイスを変更してすべてのコンパイル エラーを修正するだけで済みます。

変更がインターフェースの使用方法の変更である場合は、別の使用パターンをサポートするために別のインターフェース (おそらく別の名前) を作成する必要があります。

最終的に ISomething、ISomething2、および ISomething3 を作成したとしても、インターフェイスの利用者はインターフェイス間の違いを理解するのに苦労するでしょう。いつ ISomething2 を使用し、いつ ISomething3 を使用する必要がありますか?次に、ISomething と ISomething2 を廃止するプロセスに進む必要があります。

Answer 2

インターフェースを使いすぎていると思います。

マイヤーとマーティンは次のように語った。「拡張はオープンですが、変更はクローズです！」

そしてCwalinaらは次のように繰り返した。

フレームワーク設計ガイドラインより...

一般に、クラスは抽象化を暴露するための好ましい構成要素です。インターフェイスの主な欠点は、APIの進化を可能にすることに関して、クラスよりも柔軟性が低いことです。インターフェイスを発送すると、メンバーのセットは永久に修正されます。インターフェイスに追加されると、インターフェイスを実装する既存のタイプが破損します。

クラスではさらに柔軟性が高まります。すでに出荷されているクラスにメンバーを追加できます。メソッドが抽象的でない限り（つまり、メソッドのデフォルトの実装を提供する限り）、既存の派生クラスは変更されずに機能し続けます。

Answer 3

同意する ガロ・イェリアザリアン, 、インターフェースの変更は重大な決断です。また、新しいバージョンのインターフェイスの使用を促進したい場合は、古いバージョンを廃止済みとしてマークする必要があります。.NETでは追加できます 廃止された属性.

Answer 4

インターフェイスの目的は、at type で実装する必要がある抽象パターンを定義することです。

次のように実装する方がよいでしょう。

public interface ISomething

public class Something1 : ISomething
public class Something2 : ISomething

同じインターフェイスの複数のバージョンを作成しても、コードの再利用性やスケーラブルな設計の形で何も得られません。

Answer 5

なぜ人々があなたの投稿に反対票を投じるのかわかりません。良い命名ガイドラインは次のとおりだと思います。 とても 重要。

以前との互換性を維持する必要がある場合は、同じインターフェイスのバージョンでは、継承の使用を検討してください。新しいバージョンのインターフェイスを導入する必要がある場合は、次のルールを考慮してください。

インターフェイスに意味のあるサフィックスを追加してみてください。簡潔な名前を作成できない場合は、バージョン番号の追加を検討してください。