Élément Faire des copies défensives si nécessaire

"Vous devez programmer de manière défensive, en supposant que les clients de votre classe feront de leur mieux pour détruire ses invariants"

Java comme langage sûr :

• Java empêche les erreurs de mémoire courantes en C/C++, mais n'isole pas complètement les classes des interactions indésirables avec d'autres classes.
• Une programmation défensive est requise, en supposant que les clients de la classe puissent tenter de violer ses invariants.

Classes immuables et sécurité :

• Exemple de classe "Période" qui semble immuable mais peut être corrompue en raison de la mutabilité d'objets tels que Date.
• Solution : Faites des copies défensives des paramètres mutables lors de leur réception dans le constructeur.

public Period(Date start, Date end) { this.start = new Date(start.getTime()); // Cópia defensiva this.end = new Date(end.getTime()); if (this.start.compareTo(this.end) > 0) throw new IllegalArgumentException(start + " after " + end); }

Copies défensives chez les constructeurs :

• Des copies défensives doivent être faites avant de valider les paramètres pour éviter les vulnérabilités (ex. attaque TOCTOU).
• Évitez d'utiliser clone() pour les copies défensives d'objets potentiellement non fiables, en préférant les constructeurs statiques ou les méthodes d'usine.

Getters et mutabilité :

• Problème : les getters peuvent exposer des composants internes mutables, permettant des mutations externes.
• Solution : les getters doivent renvoyer des copies défensives des objets mutables.

public Date getStart() { return new Date(start.getTime()); // Cópia defensiva }

Application aux classes mutables :

• La copie défensive s'applique également aux classes mutables qui stockent des références aux objets mutables fournis par le client.
• Exemple : lors du stockage d'un objet dans un ensemble ou une carte, il faut se demander si l'objet peut être modifié ultérieurement.

Retour des composants internes :

• Lorsque vous renvoyez des éléments internes mutables, envisagez de renvoyer des copies défensives ou des vues immuables.

Utilisation d'objets immuables :

• Dans la mesure du possible, utilisez des objets immuables comme composants internes pour éviter d'avoir besoin de copies défensives.

Coûts et alternatives :

• Les copies défensives peuvent avoir un impact sur les performances ; Les alternatives incluent le recours à la documentation ou à des accords d'utilisation clairs.
• En cas de transfert explicite de contrôle, comme dans les modèles de conception (par exemple, wrapper), la copie défensive peut être supprimée.

Conclusion :

• Utilisez des copies défensives pour protéger l'intégrité des cours, sauf lorsque le coût est peu pratique ou qu'une confiance mutuelle est établie et qu'une documentation claire est requise.

Exemples tirés du livre :

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!