2012-06-11 6 views
6

Während durch den Selen-Quellcode suchen bemerkte ich folgende in der PageFactory:Redeklaration der Parameter

public static <T> T initElements(WebDriver driver, Class<T> pageClassToProxy) { 
    T page = instantiatePage(driver, pageClassToProxy); 
    initElements(driver, page); 
    return page; 
} 

public static void initElements(WebDriver driver, Object page) { 
    final WebDriver driverRef = driver; 
    initElements(new DefaultElementLocatorFactory(driverRef), page); 
} 

Was ist der Nutzen Sie die folgende Zeile zu haben?

final WebDriver driverRef = driver; 

Wäre es nicht sinnvoll gewesen, nur die Parameter endgültig zu machen, und dann vorbei, dass zusammen mit der nächsten Methode, ohne die neue Referenz zu deklarieren?

+3

Ja. Das wäre sinnvoller gewesen. –

+1

Vielleicht war dem Entwickler der 'final'-Modifikator nicht bekannt? lolz – user1329572

+0

Während dies die Frage nicht beantwortet, vermute ich sehr, dass es aus dem Bytecode von der jvm als No-Op kompiliert werden würde. – corsiKa

Antwort

3

Nun, die Antwort ist, dass die Einstellung final auf eine Variable und verwenden Sie es nur als Argument für eine Funktion ist völlig nutzlos. Im Konstruktor DefaultElementLocatorFactory kann die Variable, die sich auf das Eingabeargument bezieht, frei neu zugewiesen werden, da es sich um eine Kopie der ursprünglichen Referenz handelt.

P.S. ... es sei denn natürlich, wie vom OP vorgeschlagen, wird das Eingabeargument stattdessen final deklariert.

+0

Ich muss darauf hinweisen, dass ich fühle mich ziemlich lahm, diese Antwort, aber ich sehe nichts anderes zu sagen, und jemand musste, ich denke ... –

2

Das Beste, was ich mit oben kommen kann (unter der Annahme, dass die selene Devs hat mehr als ein grundlegendes Verständnis davon, wie Java funktioniert - was ich denke, ist gegeben):

Vermutlich bevor es eine DefaultElementLocatorFactory Klasse, Die Methode verwendete eine anonyme innere Funktion, und wenn der Code umstrukturiert wurde, wurden einige Teile einfach übersehen.

+0

Deshalb fragte ich, ich wollte sicherstellen, dass ich nicht war einige JVM-Bugs oder Magiefälle, die einfach nicht kommentiert wurden, verpassten. – Scott

+0

@Scott In der Tat wird final oder no final genau denselben Bytecode erzeugen, außer dass die JLS die Inlining von finalen Variablen in bestimmten Situationen erlaubt. Das ist im Grunde, wie Closures für anonyme Klassen funktionieren, wurde zuerst hinzugefügt, damit 'if (DEBUG) {]' weg optimiert werden konnte und im Allgemeinen eine entsetzliche Fehlerquelle ist. Aber das gilt nicht für Ihren gegebenen Code. – Voo

+0

Ich gab diese +1, fand aber keine Beweise für die Behauptung, dass sie von einer anonymen inneren Funktion verwendet wurde (ich habe den Commit-Verlauf im Google-Code durchgesehen). Ich vermute jedoch, dass dies wahrscheinlich ist. – Scott