Wir überprüfen die Qualität unseres Codes mithilfe von Sonar und Sonar fand Code, der Objekte auf Identität wie folgt vergleicht:
%Vor% Sonar findet diese Art der Identitätsprüfung als besonders kritisch, und schlägt vor, die Identitätsprüfung (unter Verwendung von == ) durch eine Prüfung auf Gleichheit zu ersetzen (stattdessen .equals() verwenden). Identitätskontrollen, so die Begründung dafür, sind oft nicht gemeint.
In unserem Fall durchlaufen wir jedoch eine Liste von Cell s und überprüfen in jeder Iteration ( currentCell ), ob wir eine spezielle Zelle bearbeiten, die wir bereits haben ( cellOfInterest ).
Ich würde gerne hören, ob es andere Muster gibt als unsere, die üblich sind und die dieses Problem einfach durch ein anderes Design vermeiden. Oder welche Lösungen schlagen Sie vor, eine Identitätskontrolle in der genannten Situation zu vermeiden?
Wir haben eine Ersetzung der Identitätsprüfung durch eine Gleichheitsprüfung wie oben beschrieben erwogen, aber sie scheint in unserer Situation nicht anwendbar zu sein, da andere Zellen auch "gleich", aber nicht identisch sein könnten.
Alle Ideen sind willkommen!
Wenn Identität das ist, was Sie brauchen, dann ist es das, was Sie brauchen. Die Warnung ist sinnvoll, da es sich häufig um einen Fehler handelt, in diesem Fall jedoch nicht.
Als Beispiel: IdentityHashMap (funktioniert mit identity vs Gleichheit) hat dies in seinem Javadoc:
Diese Klasse ist keine universelle Kartenimplementierung! [...] Diese Klasse ist nur für die seltenen Fälle vorgesehen, in denen Semantik für die Referenzgleichheit erforderlich ist.
So ist es selten nützlich, aber hat seine Verwendungen. Sie sind in einer ähnlichen Position. Und natürlich Der interne Code erfüllt genau das, was Sie erwarten. Er verwendet == , um einen Schlüssel zu erhalten.
Fazit: Ich sehe nicht, warum Sie den Code komplexer machen müssten, nur weil ein Tool zur statischen Codeanalyse sagt, dass es ein Problem sein könnte - ein solches Tool soll Ihnen helfen und Sie nicht in einige zwingen seltsames Konstrukt, das im Wesentlichen dasselbe macht. Ich würde erklären, warum == in einem Kommentar für Klarheit verwendet wird, markieren Sie es als falsch positiv und weitermachen.
Wenn Sie die Warnung wirklich entfernen möchten, ist die einzige Option, die ich mir vorstellen kann, die Verwendung von equals und die Änderung der Methode equals entweder:
Object#equals , der auf Identität basiert Für Strings und die meisten anderen Java-Objekte ist es möglich, zwei Instanzen zu haben, deren Identität ungleich ist, die aber tatsächlich um .equals äquivalent sind. Es ist üblich, == für einen Vergleich zu vermeiden (stattdessen equals oder compareTo), aber wenn es funktioniert, funktioniert es. Sie können das Element in SonarQube als falsch positiv markieren.
Zunächst treten keine Probleme auf, wenn Sie Ihre Identitätsprüfung einfach durch einen Gleichheitsaufruf ersetzen (außer dass Sie auf cellOfInterest nach Nullwerten suchen müssen), da die Standardimplementierung von equals in Object die Identitätsprüfung ist.
%Vor%unterbricht den Code nicht. Es verhält sich genau so wie Ihr Code, wenn ich annehmen kann, dass currentCell nicht null ist.
Um die Null-Überprüfung wegzulassen (und das Verhalten bei beiden Werten auf Null zu halten), können Sie auch (seit Java 7)
verwenden %Vor%Im Allgemeinen ist die Verwendung von equals die bessere Architektur.
Um beide Fälle anzuzeigen, haben Sie erwähnt:
Wenn die Klasse von Ihnen selbst veränderbar ist, könnten Sie (oder auch nicht) zu dem Schluss kommen, dass es bessere Möglichkeiten für Gleichheit als Identität gibt; also ändern Sie einfach die equals (und vergessen Sie nicht den hashCode!) in Ihrer Klasse.
Wenn Sie die Klasse nicht ändern können, müssen Sie auf eine sinnvolle Implementierung von equals und hashCode durch den Anbieter der Klasse vertrauen.