Quand doit-on utiliser final pour les paramètres des méthodes et les variables locales ?

Question

J'ai trouvé quelques références ( par exemple ) qui suggèrent d'utiliser final autant que possible et je me demande si c'est important. Cela concerne principalement les paramètres de méthodes et les variables locales, et non les méthodes ou classes finales. Pour les constantes, cela a un sens évident.

D'une part, le compilateur peut effectuer certaines optimisations et il rend l'intention du programmeur plus claire. D'autre part, il ajoute de la verbosité et les optimisations peuvent être triviales.

Est-ce que je dois faire un effort pour m'en souvenir ?

Answer 1

Observer :

• Champs finaux - Le fait de marquer les champs comme finaux les oblige à être définis à la fin de la construction, ce qui rend la référence du champ immuable. Cela permet une publication sûre des champs et peut éviter le besoin de synchronisation lors de lectures ultérieures. (Notez que pour une référence d'objet, seule la référence de champ est immuable - les choses auxquelles cette référence d'objet fait référence peuvent encore changer et cela affecte l'immuabilité).
• Champs statiques finaux - Bien que j'utilise maintenant les enums dans de nombreux cas où j'avais l'habitude d'utiliser des champs statiques finaux.

Pensez-y mais utilisez-les judicieusement :

• Classes finales - La conception du cadre/de l'API est le seul cas où je la considère.
• Méthodes finales - Fondamentalement identiques aux classes finales. Si vous utilisez les modèles de méthodes comme des fous et que vous marquez vos méthodes finales, vous vous appuyez probablement trop sur l'héritage et pas assez sur la délégation.

Ignorez-les, sauf si vous êtes de nature anale :

• Paramètres de méthode et variables locales - Je ne le fais que rarement, principalement parce que je suis paresseux et que je trouve que cela encombre le code. J'admets volontiers que marquer les paramètres et les variables locales que je ne vais pas modifier est plus "correct". J'aimerais que ce soit la valeur par défaut. Mais ce n'est pas le cas et je trouve le code plus difficile à comprendre avec des finales partout. Si je suis dans le code de quelqu'un d'autre, je ne vais pas les retirer mais si j'écris du nouveau code, je ne les mettrai pas. Une exception est le cas où vous devez marquer quelque chose de final pour pouvoir y accéder depuis une classe interne anonyme.

• Edit : notez qu'un cas d'utilisation où les variables locales finales sont en fait très utiles, comme mentionné par @adam-gent c'est lorsque la valeur est attribuée à la variable dans le fichier if / else branches.

Answer 2

Est-ce quelque chose que je devrais faire un effort pour me rappeler de faire ?

Non, si vous utilisez Eclipse, parce que vous pouvez configurer une action de sauvegarde pour ajouter automatiquement ces final modificateurs pour vous. Vous obtenez ainsi les avantages pour un effort moindre.

Answer 3

Les avantages de "final" en termes de développement sont au moins aussi importants que ceux en termes d'exécution. Il indique aux futurs éditeurs du code quelque chose sur vos intentions.

Le fait de marquer une classe "finale" indique que vous n'avez pas fait d'effort lors de la conception ou de la mise en œuvre de la classe pour gérer l'extension de manière gracieuse. Si les lecteurs peuvent apporter des modifications à la classe et veulent retirer le modificateur "final", ils peuvent le faire à leurs propres risques. C'est à eux de s'assurer que la classe gère bien l'extension.

Marquer une variable "finale" (et l'assigner dans le constructeur) est utile avec l'injection de dépendances. Elle indique la nature "collaboratrice" de la variable.

Marquer une méthode "finale" est utile dans les classes abstraites. Cela permet de délimiter clairement où se trouvent les points d'extension.

Answer 4

Eh bien, tout dépend de votre style... si vous AIMEZ voir la finale lorsque vous ne modifiez pas la variable, alors utilisez-la. Si vous n'AIMEZ pas la voir... alors laissez-la de côté.

Personnellement, j'aime être le moins verbeux possible, et j'ai donc tendance à éviter d'utiliser des mots-clés supplémentaires qui ne sont pas vraiment nécessaires.

Je préfère cependant les langages dynamiques, et il n'est donc pas surprenant que je veuille éviter la verbosité.

Je dirais donc qu'il suffit de choisir la direction vers laquelle vous penchez et de la suivre (quoi qu'il en soit, essayez d'être cohérent).

---

À titre d'information, j'ai travaillé sur des projets qui utilisaient et n'utilisaient pas un tel patron, et je n'ai vu aucune différence dans le nombre de bogues ou d'erreurs... Je ne pense pas qu'il s'agisse d'un modèle qui améliorera considérablement votre nombre de bogues ou quoi que ce soit, mais encore une fois, c'est un style, et si vous aimez exprimer l'intention de ne pas le modifier, alors allez-y et utilisez-le.

Answer 5

Si vous écrivez une application dont quelqu'un devra lire le code après, disons, un an, alors oui, utilisez final sur les variables qui ne doivent pas être modifiées en permanence. En faisant cela, votre code sera plus "auto-documenté" et vous réduisez également les chances pour les autres développeurs de faire des choses stupides comme utiliser une constante locale comme variable locale temporaire.

Si vous écrivez du code à jeter, alors, non, ne vous embêtez pas à identifier toutes les constantes et à les rendre finales.