Schnittstellen und Versionierung

Question

Ich entwerfe ein neues System und habe viele Schnittstellen, die im Laufe der Zeit mit dem System wachsen werden.Was ist die beste Vorgehensweise, um diese Schnittstellen zu benennen?

ISomethingV01
ISomethingV02
etc

und ich mache das

public interface ISomething{
      void method();
}

Dann muss ich Methode 2 hinzufügen. Was mache ich jetzt?

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

oder genauso anders?

Answer 1

Idealerweise sollten Sie Ihre Schnittstellen nicht sehr oft ändern (wenn überhaupt).Wenn Sie eine Schnittstelle ändern müssen, sollten Sie ihren Zweck überdenken und prüfen, ob der ursprüngliche Name noch für sie gilt.

Wenn Sie immer noch das Gefühl haben, dass sich die Schnittstellen ändern werden, die Schnittstellenänderungen gering sind (Hinzufügen von Elementen) und Sie die Kontrolle über die gesamte Codebasis haben, sollten Sie einfach die Schnittstelle ändern und alle Kompilierungsfehler beheben.

Wenn es sich bei Ihrer Änderung um eine Änderung der Art und Weise handelt, wie die Schnittstelle verwendet werden soll, müssen Sie eine separate Schnittstelle (höchstwahrscheinlich mit einem anderen Namen) erstellen, um dieses alternative Verwendungsmuster zu unterstützen.

Selbst wenn Sie am Ende ISomething, ISomething2 und ISomething3 erstellen, wird es für die Verbraucher Ihrer Schnittstellen schwierig sein, die Unterschiede zwischen den Schnittstellen herauszufinden.Wann sollten sie ISomething2 und wann ISomething3 verwenden?Dann müssen Sie den Prozess der Veraltung von ISomething und ISomething2 in Angriff nehmen.

Answer 2

Ich denke, Sie überstrapazieren die Schnittstellen.

Meyer und Martin erzählten uns:„Zur Erweiterung geöffnet, aber zur Änderung geschlossen!“

und dann wiederholten Cwalina (et al.):

Aus den Framework-Designrichtlinien...

Im Allgemeinen sind Klassen das bevorzugte Konstrukt zur Enthüllung von Abstraktionen.Der Hauptnachteil von Schnittstellen ist, dass sie viel weniger flexibel sind als Klassen, wenn es darum geht, die Evolution von APIs zu ermöglichen.Sobald Sie eine Schnittstelle versenden, ist der Satz seiner Mitglieder für immer behoben.Alle Ergänzungen zur Schnittstelle würden vorhandene Typen unterbrechen, die die Schnittstelle implementieren.

Eine Klasse bietet viel mehr Flexibilität.Sie können Mitglieder zu Klassen hinzufügen, die bereits versendet wurden.Solange die Methode nicht abstrakt ist (dh, solange Sie eine Standardimplementierung der Methode angeben), funktionieren alle vorhandenen abgeleiteten Klassen weiterhin unverändert.

Answer 3

Ich bin einverstanden mit Garo Yeriazarian, Der Wechsel der Benutzeroberfläche ist eine schwerwiegende Entscheidung.Wenn Sie die Nutzung einer neuen Version der Benutzeroberfläche fördern möchten, sollten Sie außerdem die alte Version als veraltet markieren.In .NET können Sie hinzufügen ObsoleteAttribute.

Answer 4

Der Zweck einer Schnittstelle besteht darin, ein abstraktes Muster zu definieren, das beim Typ implementiert werden muss.

Es wäre besser, es wie folgt umzusetzen:

public interface ISomething

public class Something1 : ISomething
public class Something2 : ISomething

Durch die Erstellung mehrerer Versionen derselben Schnittstelle gewinnen Sie nichts in Form von Wiederverwendbarkeit des Codes oder skalierbarem Design.

Answer 5

Ich weiß nicht, warum die Leute Ihren Beitrag ablehnen.Ich denke, das sind gute Benennungsrichtlinien sehr wichtig.

Wenn Sie die Kompatibilität mit vorheriger Version aufrechterhalten müssen.Version derselben Schnittstelle erwägen die Verwendung von Vererbung.Wenn Sie eine neue Version der Schnittstelle einführen müssen, beachten Sie die folgende Regel:

Versuchen Sie, Ihrer Schnittstelle ein sinnvolles Suffix hinzuzufügen.Wenn es nicht möglich ist, einen kurzen Namen zu erstellen, sollten Sie die Versionsnummer hinzufügen.