Frage

Ich habe die folgende API:

public interface MyApi {

   /**
    * Performs some stuff.
    * @throws MyException if condition C1
    */
   public void method() throws MyException;
}

Ich bin jetzt die folgende Änderung in meiner API-Implementierung durchführen

public class MyApiImpl {

   public void method() throws MyException {
     if (C1) {
       throw new MyException("c1 message");
     }
     ...
   }
}

wird ersetzt durch:

public class MyApiImpl {

   public void method() throws MyException {
     if (C1) {
        throw new MyException("c1 message");
     } else if (c2) {
        throw new MyException("c2 message");
     }
     ...
   }
}

Betrachten Sie dies als ein API-Bruch?

Kunden Code noch kompilieren, aber durch die API javadoc definierte Methode Vertrag wird nicht mehr beachtet, da MyExcepiton von einem „neuen“ Zustand geworfen wird.

Wenn nur meine API-JAR-Datei aktualisiert wird, wird die Kunden-Anwendung noch arbeiten, aber in Abhängigkeit von der Art und Weise fangen Kunden die Ausnahme des Anwendungsverhalten viel ändern kann.

Was ist Ihre Sicht auf das?

War es hilfreich?

Lösung

Ja, sind Sie den Vertrag der Schnittstelle zu brechen durch das Auslösen einer Ausnahme, wenn C1 nicht auf.

Als Faustregel gilt: die vageren den Schnittstelle Vertrag, desto leichter ist es nicht zu brechen :) Wenn die Schnittstelle nicht im Sinne einer expliziten C1 definiert ist, sondern in allgemeinerer Form, das gibt viel mehr Flexibilität .

Andere Tipps

Mein Standpunkt ist, dass Sie den Vertrag nicht von der API in der Dokumentation definiert ändern sollen. Wenn Sie neue Verhalten benötigen, sollten Sie entweder a.) Eine neue Methode erstellen, die vom Client aufgerufen werden können dieses neue Verhalten oder b widerspiegelt.) Diskutiert mit dem Kunden die Notwendigkeit der Veränderung und machen sie es zu wissen.

Das ist wirklich in beiden Richtungen gehen kann, ist es zwischen Ihnen und Ihren Kunden, was Ihr Ansatz sein wird.

Es hängt weitgehend davon ab, was c2 ist. Ist es innerhalb der logischen Grenzen auf den bereits bestehenden Vertrag? Wenn ja, sind erfüllen Sie den Vertrag durch eine MyException werfen. Wenn nicht, dann müssen Sie vielleicht eine neue Art von Ausnahme werfen.

Ich möchte darauf hinweisen, dass ich bin kein großer Fan von geprüften Ausnahmen. Letztlich jemand zwingt mit einer Ausnahme behandeln nicht unbedingt ihren Code oder sicherer besser machen (in der Tat kann es den gegenteiligen Effekt hat, wie sie schlampig falsche Ausnahmen schlucken können).

Ich würde sagen, „nein“, kein API Bruch, es sei denn, MyException ein Runtime ist. Dann ist es.

Wie auch immer, ich würde MyException für Bedingung C2 Unterklasse

Und beide Bedingungen C1 und C2 sollten „außergewöhnliche“ IMHO sein, würde ich nicht eine Gewohnheit zu werfen Ausnahmen

machen

Es ist ein Bruch. Ob die API von Sprachkonstrukten oder einfach dokumentiert erzwungen wird, ist irrelevant.

Ob dieser Bruch ein Problem für Client-Code verursacht, ist eine andere Frage. Es kann sein, dass Sie einen Defekt sind Befestigungs und benötigen Fall C2 auf diese Weise zu decken, es zu beheben. Von dieser Hinsicht Client-Code-Entwickler glücklich sein können, dass Sie diese Änderung vorgenommen haben (vorausgesetzt, sie um den Defekt in einer solchen Art und Weise nicht gerade arbeiten, die angesichts der Änderung brechen würde!)

Ich denke, das Problem hier ist, dass Sie einen Teil Ihrer Schnittstelle, Implementierung spezifischer Bedingungen. Wenn der „C1“ Zustand nur ein Teil Ihrer Implementierung wäre, dann könnte man einfach eine neue Implementierung erstellt hat, die eine Ausnahme auf „C1“ oder „C2“ wirft, ohne die Schnittstelle zu brechen.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top