Beim Refactoring von Methoden ist es einfach, binäre Inkompatibilitäten (mit früheren Versionen des Codes) in Java einzuführen.
Sie sollten eine Methode ändern, um den Typ ihres Parameters auf eine übergeordnete Schnittstelle zu erweitern:
%Vor%Der gesamte Code, der diese Methode verwendet, wird weiterhin ohne Änderungen kompiliert, erfordert jedoch eine erneute Kompilierung (weil die alten Binärdateien mit einem MethodNotFoundError fehlschlagen).
Wie wäre es, eine Methode in eine Elternklasse hochzuziehen? Wird dies neu kompiliert werden müssen?
%Vor%Die Methode wurde von B auf das übergeordnete Element A verschoben. Außerdem wurde die Sichtbarkeit von "geschützt" in "öffentlich" geändert (dies ist jedoch kein Problem).
Muss ich in B einen "binären Kompatibilitäts-Wrapper" pflegen, oder wird er weiter funktionieren (automatisch an die Elternklasse senden)?
%Vor%"Widening" beeinflusst die Signatur der Methode, so dass sie nicht binärkompatibel ist. Das Verschieben einer Methode in eine Superklasse wirkt sich nicht auf die Methodensignatur aus, daher wird es funktionieren. Eclipse hat ein großartiges Dokument, das API- und ABI-Kompatibilität beschreibt:
Explizitere Regeln sind Teil 2:
Ich glaube, Sie interessieren sich für "Change-Typ eines formalen Parameters" (dh was Sie als Erweiterung bezeichnen) oder "API-Methode herauf Typhierarchie verschieben" (dh was Sie als Pull in eine Elternklasse bezeichnen ).
Tags und Links java refactoring binary-compatibility