Je code en Java 8 depuis quelques années, à la fois pour de nouvelles applications et pour la migration d'applications existantes, et j'ai senti qu'il était temps d'écrire sur quelques "meilleures pratiques" que j'ai trouvées très utiles. Personnellement, je n'aime pas le terme « meilleures pratiques » car il implique une solution « taille unique », et ce n'est pas ainsi que fonctionne le codage : nous devons découvrir par nous-mêmes quelles solutions fonctionnent. Mais j'ai trouvé quelques options dans le code Java 8 qui peuvent nous aider, jetons un coup d'œil.
Optional
est une fonctionnalité sérieusement sous-estimée et a le potentiel de supprimer beaucoup de NullPointerExceptions
qui nous dérangent. Ceci est particulièrement utile dans les limites du code (soit l'API utilisée, soit l'API exposée) car cela vous permet, à vous et à votre code appelant, de raisonner sur ce à quoi vous attendre.
Cependant, l'application d'Optional sans réflexion ni conception peut affecter un grand nombre de classes et entraîner une moins bonne lisibilité. Voici quelques conseils sur la façon d’utiliser facultativement efficacement.
Facultatif ne doit être utilisé que pour les types de retour
... pas les paramètres, ni les champs. Heureusement, IntelliJ IDEA vous permet d'activer une vérification pour voir si vous suivez ces recommandations.
Les valeurs facultatives doivent être traitées là où elles sont rencontrées. Les suggestions d'IntelliJ IDEA éviteront les fuites d'option dans votre code, alors n'oubliez pas de gérer Optionnel partout où vous le trouvez et agissez rapidement.
ne devrait pas simplement appeler get()
La fonction de Optionnel est d'exprimer que cette valeur peut être vide et de vous permettre de gérer cela situation . Par conséquent, assurez-vous de vérifier s’il existe une valeur avant de faire quoi que ce soit avec elle. Le simple fait d'appeler get()
sans vérifier d'abord isPresent() peut entraîner un pointeur nul à un moment donné. Heureusement, IntelliJ IDEA propose également des vérifications pour vous le rappeler.
Il existe peut-être une manière plus élégante
Le isPresent()
combiné avec get() serait certainement génial...
… mais il existe des solutions plus élégantes. Vous pouvez utiliser orElse pour proposer une alternative au cas où la valeur serait nulle.
…ou vous pouvez utiliser orElseGet
pour indiquer quelle méthode appeler si la valeur est nulle. Cela semble être le même que l'exemple ci-dessus, mais la méthode supplier ne sera appelée qu'en cas de besoin, donc s'il s'agit d'une méthode coûteuse, les performances seront meilleures en utilisant un lambda.
Les expressions Lambda sont l'une des principales fonctionnalités de Java 8. Même si vous n’avez pas encore utilisé Java 8, vous en avez probablement déjà une compréhension de base. Il s’agit d’une nouvelle façon de programmer en Java, et ce que sont les « meilleures pratiques » n’est pas encore évident. Voici quelques directives que j’aime suivre.
Soyez bref
Les programmeurs fonctionnels seront plus heureux avec des expressions lambda plus longues, mais ceux qui sont immergés dans Java depuis de nombreuses années trouvent il est plus facile de limiter les expressions lambda à quelques lignes de code. Vous préférerez peut-être même le limiter à une seule ligne de code et vous pourrez facilement refactoriser des expressions plus longues dans une méthode.
Ceux-ci peuvent même devenir des références de méthodes. Les références de méthodes peuvent sembler un peu inhabituelles au début, mais il est en fait utile de s'en tenir aux références de méthodes car elles facilitent la lisibilité dans certaines situations, dont je parlerai plus tard.
Explicit
Les informations de type sont manquantes dans les expressions lambda, vous trouverez donc peut-être utile d'inclure des informations de type pour les paramètres.
Comme vous pouvez le constater, cette fois, ça devient assez maladroit. Je préfère donc donner aux paramètres un nom utile. Bien entendu, que vous l'ayez fait ou non, IntelliJ IDEA vous permet de voir les informations de type des paramètres.
Même l'interface fonctionnelle représentée par lambda :
Je pense que les expressions lambda sont un peu comme les génériques - avec les génériques, nous les utilisons souvent (par exemple, en ajoutant des informations de type à une List<>), mais mieux nous pouvons concevoir une méthode ou une méthode avec des génériques. Une classe de type ( par exemple Person<T>
). De même, lorsque nous utilisons quelque chose comme l'API Streams, nous transmettons une expression lambda, mais le mieux est de créer une méthode qui nécessite un paramètre lambda.
Mais si vous vous trouvez dans cette situation, voici quelques conseils géniaux.
IntelliJ IDEA peut vous aider à introduire des paramètres fonctionnels
Cela vous permet de créer un paramètre où quelqu'un passerait un lambda au lieu d'un objet. L'avantage de cette fonctionnalité est qu'elle montre que l'interface fonctionnelle existante correspond à la spécification.
Cela se traduit par...
Utilisation des interfaces fonctionnelles existantes
À mesure que les développeurs deviennent de plus en plus familiers nous sommes avec du code Java 8, nous savons ce qui se passe lors de l'utilisation d'interfaces telles que Supplier
et Consumer, et comment la création d'un ErrorMessageCreator local (par exemple) peut être déroutante et inutile. Jetez un œil à ce package pour voir ce qui est déjà disponible.
Ajoutez @FunctionalInterface à l'interface fonctionnelle
Si vous avez vraiment besoin de créer votre propre interface fonctionnelle, marquez-la avec cette annotation en tant que telle. Cela peut ne pas sembler avoir beaucoup d'effet, mais IntelliJ IDEA vous indiquera quand votre interface ne peut pas correspondre aux exceptions utilisées pour les interfaces fonctionnelles. Lorsque vous ne spécifiez pas de méthode à remplacer, il signalera :
Lorsque vous spécifiez trop de méthodes, il signalera :
Et si vous l'appliquez à une classe au lieu d'une interface, il vous avertira :
les expressions lambda peuvent être utilisées Toute interface avec une seule méthode abstraite, mais elle ne peut pas être utilisée avec des classes abstraites répondant aux mêmes critères. Cela semble illogique, mais c'est ce que c'est.
L'API Stream est une autre fonctionnalité importante de Java 8, et je pense que nous ne savons vraiment pas à quel point cela changera sur la façon dont nous codons. Voici quelques éléments que j’ai trouvés utiles.
Opérateurs de points de file d'attente
Personnellement, je préfère mettre en file d'attente mes opérations de flux. Bien sûr, vous n'êtes pas obligé de faire cela, car j'ai trouvé utile de le faire :
Voir en un coup d'œil quelles opérations j'ai
Débogage plus facile (bien qu'IntelliJ IDEA offre la possibilité de définir des points d'arrêt sur n'importe quel nombre d'expressions lambda dans une ligne, le fractionnement en différentes lignes serait plus simple)
Commentez les actions lorsque je je teste des trucs
Insérez facilement peek()
pour le débogage ou les tests
En plus, c'est plus soigné à mon avis. Si nous suivons ce schéma, nous ne gagnerons pas grand chose en termes de réduction de lignes de code.
Vous devrez peut-être ajuster vos paramètres de formatage pour aligner les opérateurs de points.
Utiliser des références de méthodes
Oui, il faut un certain temps pour s'habituer à cette syntaxe étrange. Cependant, s’il est utilisé correctement, il améliore la lisibilité. Voir :
par rapport aux méthodes d'assistance sur la (relativement) nouvelle Objects
classe :
Cette dernière le code est plus explicite sur les valeurs qui doivent être enregistrées. IntelliJ IDEA vous indiquera généralement quand un lambda peut être réduit en référence de méthode.
Lorsque vous parcourez une collection, utilisez l'API Streams
… ou de nouvelles méthodes de collecte comme forEach
lorsque cela est possible. La suggestion d'IntelliJ IDEA pour vous est la suivante :
Généralement, l'utilisation de l'API Streams est plus claire que la combinaison de boucles et d'instructions if. Par exemple :
IntelliJ IDEA suggère que cela peut être refactorisé en :
Les tests de performances que j'ai effectués montrent cette refactorisation est surprenant : il n'est pas toujours prévisible si les performances resteront les mêmes, s'amélioreront ou se détérioreront. Comme toujours, si les performances sont essentielles dans une application, mesurez-les avant de confier un style à un autre.
Utilisez des boucles lors d'une itération sur des tableaux
Cependant, utiliser Java 8 ne signifie pas nécessairement que vous devez utiliser des flux et de nouvelles méthodes de collecte partout. IntelliJ IDEA vous proposera de convertir en flux, cependant, cela ne signifie pas que vous devez répondre « oui » (rappelez-vous que la vérification peut être supprimée ou désactivée).
En particulier, le bouclage sur de petits tableaux de types primitifs sera presque certainement utilisé pour de meilleures performances et probablement (au moins pour les développeurs Java novices dans les flux) plus lisible.
Comme pour toute technique, les règles ne sont pas gravées dans le marbre, mais vous devez décider si vous souhaitez utiliser l'API Streams autant que possible, ou toujours utiliser des boucles pour certaines opérations. . Bref, soyez cohérent.
Ce qui précède est le contenu des principales compétences de développement Java 8. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (m.sbmmt.com) !