Mises à jour des notes personnelles en vigueur de Java Third Edition 2nd Edition

La * 3e édition effective de Java * que j'ai commandée est enfin arrivée, j'ai donc résumé les changements de la deuxième édition. J'ai sauté les notes personnelles et les parties qui ne sont pas différentes de la deuxième édition, alors pardonnez-moi toute omission. La deuxième édition faisant référence à la version japonaise, il peut y avoir des incohérences par rapport au texte traduit. Je vous serais reconnaissant de bien vouloir signaler toute erreur.

Guide d'utilisation

Citation de Effective Java Third Edition ou sa traduction

• Résumé du contenu

Texte brut - Impression individuelle

Item 2

Un générateur avec des paramètres récursifs a été ajouté. Vous pouvez facilement concevoir des sous-classes en définissant le générateur retourné par la classe abstraite parente Pizza sur Builder <T extend Builder <T >> ʻet le type renvoyé par sa méthode ʻaddTopping () sur T. ..

Point 5: utiliser l'injection de dépendances plutôt que des ressources de code en dur

** Les classes d'utilité statique et les singletons ne conviennent pas aux classes dont le comportement peut être paramétré par des ressources **

• Passez Fournisseur <T> plutôt que Passez l'usine.

Item 6

L'exemple de création d'objets inutiles est passé de l'utilisation de Calendar à String.matches () (le problème est qu'il crée Pattern à chaque fois).

Point 8: éviter les finisseurs et les nettoyants

Le nettoyeur ajouté dans Java 9 a été évoqué.

** Les nettoyants ne sont pas aussi dangereux que les finaliseurs, mais ils sont toujours imprévisibles, lents et généralement inutiles **

• attaque du finaliseur --Utilisez le finaliseur pour laisser l'objet défectueux dans le tas et appeler la méthode (la description elle-même était dans la 2ème édition, mais elle est plus accentuée)

• Devrait implémenter ʻAutoCloseable` à la place

Point 9: Utilisez try-with-resources plutôt que try-finally

• Try-finally est facile à faire des erreurs (erreur de blocage, erreur d'implémentation JDK)

Item 10

• ʻEquals () ʻest difficile à implémenter. Utilisez AutoValue ou laissez l'EDI le générer

Personnellement, je n'aime pas beaucoup AutoValue, alors j'utilise Lombok ou je l'écris en Kotlin.

IDEs do not make careless mistakes, and humans do Les IDE ne font pas d'erreurs par inadvertance, mais les humains le font

Item 11

L'exemple de code a été modifié pour utiliser «Type.hashCode ()» (comme «Short.hashCode ()») pour générer le code de hachage. En ce qui concerne la documentation pour générer hashCode, l'expression est devenue plus forte de "ne pas le faire" à "ne pas le faire" (la documentation rend impossible de changer dans le futur).

Item 12

• Vous n'avez pas besoin de toString () dans les classes utilitaires statiques ou les énumérateurs

Item 13

• Les classes immuables ne doivent pas fournir de clonable (peuvent être partagées sans copier en premier lieu)

Item 14

• Utilisez Type.compare ()
• Utilisez Comparator.comparing ... ()
• N'utilisez pas de comparateurs basés sur des différences (ceux qui soustraient des valeurs entre objets) (débordement)

Item 15

• On ne sait pas encore si les modules Java 9 seront largement utilisés.
• Le module est ʻadvisory`. Vous n'êtes pas obligé de le forcer.

Item 19

• Utilisez @ implSpec

Item 20

• Les classes abstraites sont toujours utiles car les méthodes par défaut sont utiles mais limitées.

Point 21: Concevoir l'interface pour l'avenir

** Il n'est pas toujours possible d'écrire une méthode par défaut sans changer toutes les implémentations possibles ** ** Il est toujours primordial de faire très attention lors de la conception d'une interface **

• par exemple Apache Commons synchronizedCollection La méthode par défaut n'est pas synchronisée (jusqu'à ce qu'elle soit remplacée)!
• Ne vous sentez pas libre de concevoir une interface simplement parce qu'elle a une méthode par défaut

Ancien article 21

Supprimé, fusionné dans l'élément 42

Item 24

• Avec l'ajout de lambdas, les objets de fonction et de processus ne sont plus nécessaires

Élément 25: écrire une seule classe de premier niveau dans le fichier source

• Si vous créez par erreur une source avec le même nom, vous ne pourrez peut-être pas la compiler.

Vous pouvez écrire plusieurs classes publiques dans un langage comme Kotlin, mais je pense qu'il est préférable de les séparer autant que possible pour plus de lisibilité.

Point 26: ne pas utiliser de prototype

"Avec un nouveau code" est parti (pas de refactorisation forcée)

Item 27:

Description de l'opérateur diamant

Item 30

Avec l'ajout de l'opérateur losange, la description de la méthode utilitaire newHashMap pour omettre les paramètres de type a disparu lors de la création d'une nouvelle collection.

generic singleton pattern

private static UnaryOperator<Object> IDENTITY_FN = (t) -> t;
@SuppressWarnings("unchecked")
public static <T> UnaryOperator<T> identityFunction() {
    return (UnaryOperator<T>) IDENTITY_FN;
}

Je ne pense pas avoir beaucoup d'occasions de l'utiliser dans des batailles réelles.

Point 32: Combinez soigneusement les types génériques et les arguments de longueur variable

• Utilisez toujours @ SafeVarargs et arrêtez en cas de danger

Item 34

Convertir de String en Enum

private static final Map<String, Operation> stringToEnum = Stream.of(values()).collect(toMap(Object::toString, e -> e));
public static Optional<Operation> fromString(String symbol) {
    return Optional.ofNufllable(stringToEnum.get(symbol));
}

Je souhaite personnellement lever une exception (traitée au point 55).

Le «jour de la paie» a été subtilement remanié.

Item 37

Pourquoi avez-vous changé Herb en Plant et Type en Lifecycle?

Item 39

JUnit -> JUnit 3 JUnit 4 est basé sur des annotations, je suis donc exactement les conseils de cette section.

Point 42: Utilisez lambda au lieu d'une classe anonyme

Les types de paramètres Lambda ne sont pas utilisés sauf si cela rend le programme plus propre. Lambda manque de nom et de documentation. N'utilisez pas de lambdas si le processus n'est pas explicite ou s'il dépasse quelques lignes.

• Si vous avez besoin d'une référence à vous-même, vous avez besoin d'une classe anonyme
• Lambda ne doit pas être sérialisé

Point 43: utiliser des références de méthode au lieu de lambda

• S'il est plus concis d'utiliser lambda, faites-le (par exemple, Function :: identity vs x-> x)

Point 44: utiliser l'interface fonctionnelle standard

Le modèle "méthode modèle", dans lequel les sous-classes remplacent les "méthodes primitives" pour personnaliser le comportement des superclasses, est beaucoup moins attrayant. Une alternative moderne consiste à fournir une fabrique ou un constructeur statique qui accepte les objets fonction qui font la même chose.

• Utilisez le standard plutôt que de créer votre propre interface fonctionnelle

• Lors de la définition de votre propre interface fonctionnelle

• Largement utilisé et bénéficiant de noms descriptifs

• Si vous avez un contrat fortement lié

• Si vous bénéficiez de votre propre méthode par défaut

• Utilisez @ FunctionalInterface

Ne créez pas différentes méthodes surchargées qui ont des interfaces fonctionnelles différentes dans la même position que les arguments si elles peuvent être ambiguës pour le client.

• Par exemple, ʻExecutorService.submit () ʻest difficile à comprendre car il prend Runnable et Callable <T>.

Point 45: Utilisez les flux avec prudence

just because you can doesn't mean you should

** La surutilisation des flux rend le programme difficile à lire et à maintenir **

Ça me fait mal aux oreilles

** L'utilisation de méthodes d'assistance dans le code qui utilise des pipelines de flux est encore plus importante que dans le code qui utilise des itérateurs. ** **

• N'utilisez pas Stream pour char

Le nom de la méthode (primes) est une nomenclature plurielle qui décrit les éléments du flux. Cette convention de dénomination améliore la lisibilité du pipeline de flux et est fortement recommandée pour toutes les méthodes qui renvoient un flux.

Point 46: utiliser une fonction sans effets secondaires dans le flux

• Pour utiliser Stream, vous devez vous adapter au paradigme (de la programmation fonctionnelle) ainsi qu'à l'API.

L'instruction forEach ne doit être utilisée que pour rapporter les résultats du traitement d'un flux, pas pour effectuer un traitement.

Il est facile de dire forEach (e-> list.add (e)).

Élément 47: utilisez la collection plutôt que le flux pour la valeur de retour

Si vous écrivez une API publique qui renvoie une séquence, vous devez l'écrire non seulement pour ceux qui veulent écrire des pipelines de flux, mais aussi pour ceux qui veulent écrire des instructions for-each.

** Ne stockez pas de grandes séquences en mémoire juste pour les renvoyer sous forme de collection. ** **

Envisagez d'implémenter une collection dans un but particulier.

Point 48: Paralléliser soigneusement les flux

** Si la source est Stream.iterate ou si la limite de l'opération intermédiaire` est utilisée, la parallélisation du pipeline n'améliorera pas les performances. ** **

• Ne parallélisez pas les flux sans discernement

** La mise en parallèle des flux d'instances ʻArrayList, HashMap, HashSet, ConcurrentHashMap, les tableaux, la plage ʻint et la plage longue a le plus grand gain de performance. Faisons le. ** **

• La parallélisation des flux non seulement ralentit les performances, mais peut également entraîner des résultats incorrects et un comportement imprévisible.

• Différence entre forEach et forEachOrdered

• Guide approximatif: les performances peuvent s'améliorer si `` éléments de flux x lignes de code> 100000 '' est dépassé Source dans le livre: Quand utiliser des flux parallèles

Il est important de se rappeler que la parallélisation de flux est une optimisation des performances. Comme pour toute optimisation, vous devez mesurer les performances avant et après la modification pour vous assurer que vous devez le faire.

Item 49

• Utilisez ʻObjects.requireNonNull`

Item 50

** Date est obsolète et ne devrait plus être utilisée dans le nouveau code **

Article 55: retourner soigneusement en option

** Les types de conteneurs et les options telles que les cartes, les flux et les tableaux ne doivent pas être facultativement enveloppés. Déclarez une méthode pour renvoyer ʻOptional `si elle ne renvoie pas de résultat, * et *, et que le client doit faire quelque chose de spécial. ** **

• Utilisez ʻOptionalInt, ʻOptionalLong, ʻOptionalDouble. Si c'est ʻOptional <T> , la boxe automatique se produira et les performances se détérioreront.

• N'utilisez pas d'options pour les clés de collection ou de tableau, les valeurs ou les éléments

• La sauvegarde des options dans les champs est souvent un code "odorant", mais cela peut aussi être justifié (par exemple, si vous avez beaucoup de champs optionnels et que vous avez juste besoin de renvoyer le optionnel du getter).

Item 56

• Utilisez @ implSpec
• Notez le point (considéré comme la fin de la phrase)

Item 59

• Utilisez ThreadLocalRandom plutôt que Random
• Guava est pratique

Ancien élément 73: éviter les groupes de fils

Effacer

Item 75

• Ajout d'un constructeur avec ʻint index comme argument à ʻIndexOutOfBoundsException dans Java 9.

Élément 80: Sélectionnez l'exécuteur, la tâche et le flux à partir du thread

Le flux a été ajouté en tant que candidat.

Point 85: Utilisez des alternatives plutôt que la sérialisation Java

Le danger de la sérialisation est fortement souligné.

• Étude de cas: [San Francisco Municipal Railway](https://ja.wikipedia.org/wiki/%E3%82%B5%E3%83%B3%E3%83%95%E3%83%A9%E3%83 % B3% E3% 82% B7% E3% 82% B9% E3% 82% B3% E5% B8% 82% E5% 96% B6% E9% 89% 84% E9% 81% 93) [sur deux jours Stop](https://arstechnica.com/information-technology/2016/11/san-francisco-transit-ransomware-attacker-l probable-used-year-old-java-exploit/)
• Vulnérabilités des collections Apache Commons

** Le meilleur moyen d'éviter les vulnérabilités de sérialisation est de ne rien désérialiser ** ** Il n'y a aucune raison d'utiliser la sérialisation Java sur les systèmes nouvellement écrits **

• Alternative: JSON, Protobuf

La meilleure chose à faire est de ** ne jamais désérialiser les données non fiables **

• Si vous avez vraiment besoin d'un sérialiseur, utilisez java.io.ObjectInputFilter

En conclusion, la sérialisation est dangereuse et ne doit pas être utilisée.

Impressions

• Concernant les pièces neuves, il n'y a que du bon sens et rien de nouveau
• Cependant, est-il utile de réapprendre le bon sens?
• Comme prévu, il met en garde contre l'utilisation aveugle des flux
• Il est très bien que le danger de sérialisation soit souligné
• La publicité de Google augmente (M. Brock est un ancien employé de Google)
• Il a été révisé dans son ensemble, donc si vous ne l'avez pas encore, vous devriez l'acheter dès qu'une traduction japonaise sera disponible. Je me demande si ceux qui en ont ont besoin d'en acheter un nouveau.

Bonus - PC de M. Brock