Il y a beaucoup de bonnes réponses, mais il y a une autre raison très mineure à mettre thispartout. Si vous avez essayé d'ouvrir vos codes source à partir d'un éditeur de texte normal (par exemple le bloc-notes, etc.), l'utilisation thisle rendra beaucoup plus clair à lire.
Imagine ça:
public class Hello {
private String foo;
// Some 10k lines of codes
private String getStringFromSomewhere() {
// ....
}
// More codes
public class World {
private String bar;
// Another 10k lines of codes
public void doSomething() {
// More codes
foo = "FOO";
// More codes
String s = getStringFromSomewhere();
// More codes
bar = s;
}
}
}
C'est très clair à lire avec n'importe quel IDE moderne, mais ce sera un cauchemar total à lire avec un éditeur de texte normal.
Vous aurez du mal à savoir où fooréside, jusqu'à ce que vous utilisez la fonction "trouver" de l'éditeur. Ensuite, vous crierez getStringFromSomewhere()pour la même raison. Enfin, après avoir oublié ce qui sest, cela bar = sva vous donner le coup de grâce.
Comparez-le à ceci:
public void doSomething() {
// More codes
Hello.this.foo = "FOO";
// More codes
String s = Hello.this.getStringFromSomewhere();
// More codes
this.bar = s;
}
- Vous savez,
fooc'est une variable déclarée dans la classe externe Hello.
- Vous savez,
getStringFromSomewhere()c'est aussi une méthode déclarée dans la classe externe.
- Vous savez que cela
barappartient à la Worldclasse et qu'il ss'agit d'une variable locale déclarée dans cette méthode.
Bien sûr, chaque fois que vous concevez quelque chose, vous créez des règles. Ainsi , alors que la conception de votre API ou d'un projet, si vos règles sont « si quelqu'un ouvre tous ces codes sources avec un bloc - notes, il doit lui tirer dessus / elle - même dans la tête » , alors vous êtes tout à fait bien de ne pas faire cela .