5 Réponses :
Les champs finaux vous empêchent de changer le champ lui-même (en le faisant "point" à une autre instance), mais si le champ est une référence à un objet mutable, rien ne vous empêchera de le faire:
public class Person {
private final String firstName;
private final String lastName;
public Person(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;
}
//getters and other methods here
}
Cette citation dit que ce qui est dit:
Faire finale tous les champs à moins d'être mutable
champ mutable est un champ que vous pouvez modifier ultérieurement pour pointer vers un autre objet. Si le champ est
final , il peut toujours faire référence à un objet mutable (E.G.java.util.date ). Ainsi, le champ est immuable (pointe toujours vers le même objet), mais cet objet est mutable.
@Thomasz Veuillez citer la source de la citation. Java efficace ??
@Geek. PSST! Voir votre propre question, vous pouvez trouver ce que vous recherchez là-bas. ;-)
Conformément à la convention de code Java Les variables finales sont traitées comme constantes et écrites dans toutes les capuchons, par exemple
private final List Loans = new ArrayList();
list.add(“home loanâ€); //valid
list.add("personal loan"); //valid
loans = new Vector(); //not valid
en finale Java est simileur à ceci:
Dans les champs finaux Java ne peut pas être changé, mais l'objet à qui ils se réfèrent peut changer par son propre.
Ex. de vos questions:
Pour simplement éviter toute modification (logiquement ou accidentelle) à l'original, il est toujours bon de les faire définir. int * const p = & quelque chose // pointeur constant.in c ++. Vous ne pouvez pas utiliser ce pointeur pour changer quelque chose, mais que quelque chose peut être changé avec son propre.
'this' est final, vous ne pouvez rien attribuer à ceci mais vous pouvez attribuer à l'objet à qui cela se réfère.
C'est une bonne pratique pour rendre tous les champs final à moins qu'ils doivent être mutables.
Je sais que const en C ++ et finale en Java ne sont pas équivalents. Je sais aussi quels moyens finaux pour les références. Ma question concerne les formulations dans la citation de JCIP.
Je vous donne la référence à C ++ alors faites la différence très claire et facile à comprendre.
Ne tenez pas compte de la citation. Il n'ya guère de bénéficier de votre code bloqué avec Généralement, il y a deux écoles. Choisissez le vôtre:
One ne doit pas utiliser L'autre est émis avec sur ma part Je voudrais juste que vous sachiez que final de temps en temps. L'auteur visait une bonne pratique, mais dans les grandes bases de code, voir tout ce qui est fait finalement obscurcit l'intention, rendant le code de lecture plus difficile et plus obscur - et peut donner peu à aucun avantage.
Deux approches
final , à moins que vous ne souhaitiez vraiment pas lire le code que vous avez écrit de savoir que ce champ est spécial d'une manière ou d'une autre, ne doit pas être soigné.
final et le souhaite partout. C'est moins répandu. Renauld Waldura fait pour un excellent propagateur de l'idée. Lisez son entrée liée, intitulée "mot final sur le mot-clé final" , c'est une lecture bonne et approfondie.
peut dépendre de Java que vous utilisez
final a changé, et ne signifie pas toujours le somptable, comme vous pouvez le lire dans
Vous vous confondez le champ étant mutable, et l'objet Le champ se réfère à être mutable. La valeur du champ
final en elle-même ne peut pas être modifiée, l'état de l'objet pointe pour pouvoir. (Cela pourrait faire partie de la justification pourquoi ils s'appellentfinal et nonconst , pour éviter toute confusion avec la fonctionnalité C ++ pouvant appliquer des restrictions plus fortes.)Voici une explication du mot clé finale Javarevisited. blogspot.co.at/2011/12/... avec des exemples.
@Geek la question entre les lignes? Que diriez-vous de l'épeler à la place. Tout ce que j'ai dit, c'est qu'un champ et l'objet il pointe des points différentes choses . La citation ne dit que si
final fait les champs immuables. Cela ne dit rien des objets est donc logique.