Gegeben der folgende nicht sehr nützliche Code:
%Vor%(Bitte korrigieren Sie mein Verständnis, wenn es falsch ist!)
Der zweite Aufruf von fancy() ist ein Compilerfehler, da Java keinen gemeinsamen Typ zwischen den beiden Argumenten ableiten kann ( Object kann nicht abgeleitet werden, da der zweite Parameter ein Collection sein muss).
Der Aufruf von plain() ist nicht ein Compilerfehler, da Java den allgemeinen Typ von Object zwischen den beiden Argumenten ableitet.
Ich bin kürzlich auf Code gestoßen, der eine ähnliche Methodensignatur wie plain() hat.
Meine Frage ist das:
Ist die plain() -Signatur für irgendetwas nützlich?
Vielleicht hat die Person, die diesen Code geschrieben hat, gedacht, dass die Signatur von plain() erzwingen würde, dass beide Parameter zur Kompilierungszeit den gleichen Typ haben, was offensichtlich nicht der Fall ist.
Gibt es einen Unterschied zum Schreiben einer Methode mit einer Signatur wie plain() , oder profitieren Sie davon, anstatt beide Parameter nur als Object s zu definieren?
Während der Compiler nicht den generischen Typ ableitet, den man beabsichtigen könnte, wird
Die parametrisierte Methode & lt; String & gt; plain (String, String) vom Typ Test ist nicht anwendbar für die Argumente (String, ArrayList & lt; Integer & gt;)
Ich denke, Sie könnten sagen, dass es sich um eine Art Dokumentation handelt, so dass der Benutzer weiß, dass Sie erwarten, dass beide Argumente vom selben Typ sind. Natürlich sind any zwei Objekte bis zu einem gewissen Grad vom selben Typ (sie sind alle Object ), also ist es eine bedeutungslose Aussage.
Lange Rede, kurzer Sinn, es ist eine nutzlose Unterschrift.
Natürlich, wenn plain einen Typ T zurückgegeben hat, wäre das eine andere Geschichte.
Der zweite Aufruf von fancy () ist ein Compilerfehler, weil Java nicht schließen kann ein beliebiger gemeinsamer Typ zwischen den beiden Argumenten (kann Objekt seit nicht ableiten) Der zweite Parameter muss eine Collection sein.)
Nun, ich bin nicht sicher, dass dies der Grund ist, ich würde sagen, der Grund ist, dass der generische Typ T in Collection<T> eine Invariante ist, deren Wert den Typ des ersten Parameters T bestimmt.
Dies ist zum Beispiel gültig:
%Vor% Weil alle String CharSequences sind. Es wird erwartet, dass der erste Parameter ein CharSequence ist, sobald der Typ von ArraysList<CharSequence> abgeleitet wurde.
Dies ist jedoch nicht gültig:
%Vor% Da erwartet wird, dass der Typ des ersten Parameters String ist, und wir nicht sicherstellen können, dass alle CharSequences tatsächlich vom Typ String sind, richtig?
Also, AFAIK, der Grund, warum die Typen nicht kompatibel sind, liegt in der Natur der Generika in diesem Fall und nicht in der Tatsache, dass der zweite Typ ein Collection ist.
Tags und Links java generics type-inference