[Effective Java 3rd Edition](https://www.amazon.co.jp/Effective-Java-%E7%AC%AC3%E7%89%88-%E3%], qui est un livre indispensable pour les utilisateurs Java intermédiaires et supérieurs. 82% B8% E3% 83% A7% E3% 82% B7% E3% 83% A5% E3% 82% A2% E3% 83% BB% E3% 83% 96% E3% 83% AD% E3% 83% 83% E3% 82% AF-ebook / dp / B07RHX1K53) a une version Kindle, donc je vais le résumer.

Précédent: Effective Java 3rd Edition Chapter 7 Lambda and Stream Suivant: Programme général du chapitre 9 du chapitre 9 de Java, 3e édition

Point 49 Vérifier la validité des paramètres

Pour les méthodes publiques et protégées, utilisez la balise Javadoc @ throws pour documenter les exceptions qui sont levées si les contraintes de valeur de paramètre ne sont pas respectées. Généralement, les exceptions sont ʻIllegalArgumentException, ʻIndexOutOfBoundsException, NullPointerException.
La méthode ʻObjects.requireNonNull` ajoutée dans Java7 est flexible et pratique, vous n'avez donc pas à faire une vérification manuelle des null.

//Lève une NullPointerException si la stratégie est nulle
this.strategy = Objects.requireNonNull(strategy, "strategy must not be null.")

--Dans Java 9, un mécanisme de vérification de plage a été ajouté à java.util.Objects. Il se compose de trois méthodes, checkFromIndexSize, checkFromToIndex et checkIndex, et vérifie si l'index de la liste et du tableau se trouve dans la plage.

Les méthodes non publiques doivent utiliser des assertions pour vérifier les paramètres.

Article 50 Copie défensive si nécessaire

Lorsqu'un objet variable tel que la classe Date entre en tant que paramètre, il est important de le copier de manière défensive.

Point 51 Concevoir soigneusement la signature de la méthode

--Choisissez soigneusement le nom de la méthode. Évitez les noms de méthode longs.

Ne fournissez pas trop de méthodes utiles. Les méthodes individuelles doivent «jouer leur propre rôle» et de nombreuses méthodes rendent les tests et la maintenance difficiles.
Évitez les longues listes de paramètres. Visez 4 ou moins. Il est dangereux d'avoir plusieurs paramètres du même type. Il existe trois techniques pour raccourcir la liste des paramètres trop longs: --Split les méthodes de sorte que chaque méthode ne nécessite qu'un sous-ensemble des paramètres. --Créez une classe d'assistance qui contient une collection de paramètres.
Appliquez le modèle Builder de la création d'objet à l'appel de méthode. --Pour le type de paramètre, sélectionnez l'interface plutôt que la classe. S'il existe une interface appropriée pour définir les paramètres, utilisez cette interface plutôt que la classe qui l'implémente. (Exemple: HashMap → Map)
Si la signification de boolean n'est pas claire à partir du nom de la méthode, utilisez le type enum avec deux éléments plutôt que boolean.

Point 52 Utiliser prudemment la surcharge

En surcharge, la sélection de la méthode appelée est effectuée au moment de la compilation. Dans une instance Collection, si le contenu est ʻArrayList, ʻArrayList ne peut pas appeler avec succès la méthode d'argument.
Une politique sûre et conservatrice ne fournit pas deux méthodes surchargées avec le même nombre de paramètres. Au lieu de surcharger, donnez à la méthode un nom différent.

Point 53: Utilisez des arguments de longueur variable avec prudence

Le problème est que la méthode d'argument de longueur variable ne peut être vérifiée à l'exécution que lorsqu'un ou plusieurs arguments sont requis. --Placez un argument de longueur variable après les paramètres requis.

Élément 54 Renvoie une collection vide ou un tableau vide au lieu de null

Ne retournez pas null au lieu d'une collection vide ou d'un tableau vide.
Si nul, il sera difficile d'utiliser l'API et il n'y aura aucun avantage en termes de performances.

Point 55: retourner soigneusement l'option

Il existe trois manières de représenter des objets sans valeur. --null (danger de NullPointerException) --Exception (coût élevé) --En option (à partir de java8) --ʻOptional.empty () ʻempty. Facultatif qui contient une valeur dans ʻOptional.of (value) . --ʻOptional.ofNullable (value) détermine et renvoie l'un des éléments ci-dessus selon que la valeur est nulle ou non.
Les méthodes qui renvoient facultatif ne doivent pas renvoyer null.
Le retour d'une option qui inclut un type de données de base en boîte est coûteux car vous effectuez deux niveaux de boxe. Par conséquent, les types de données de base ʻOptionalInt, ʻOptionalLong et ʻOptionalDouble` sont préparés.
Il devrait être rare d'utiliser une option facultative autre que la valeur de retour.

Élément 56 Rédiger des commentaires de document pour tous les éléments publics de l'API

Les commentaires de document doivent être écrits avant toutes les déclarations de classes, interfaces, constructeurs, méthodes et champs publiés.
Les commentaires des documents sur les méthodes doivent décrire brièvement le contrat entre la méthode et ses clients.
Répertoriez toutes les conditions préalables, postconditions et effets secondaires de la méthode.
Les balises @ param, @ return et @ throws doivent être écrites.
Les commentaires de document sont convertis en HTML, vous pouvez donc utiliser des balises HTML.
Lors de la conception d'une classe pour l'héritage, le modèle d'auto-utilisation doit être documenté. Pour cela, utilisez @ implSpec. -Méta caractères HTML (<``>``&Etc.) lors de l'utilisation@literalEntourez les balises. Exemple){@literal |r| < 1}

Méthodes efficaces du chapitre 8 de Java 3rd Edition