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 eu l'impression 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.
Facultatif est une fonctionnalité sérieusement sous-estimée et a le potentiel de supprimer de nombreuses NullPointerExceptions qui nous tourmentent. 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.
Optional 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.
Vous ne devez pas simplement appeler get()
La fonction de Optionnel est d'exprimer que la valeur peut être vide et de vous permettre de gérer cette situation. Par conséquent, assurez-vous de vérifier s’il existe une valeur avant de faire quoi que ce soit avec elle. Appeler simplement get() sans vérifier au préalable 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
Bien sûr, isPresent() combiné avec get() serait 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 vide. 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 satisfaits des expressions lambda plus longues, mais ceux qui sont immergés dans Java depuis de nombreuses années trouveront qu'il est plus facile de conserver les expressions lambda sur 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.
Explicite
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, c'est devenu 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, ajouter des informations de type à une liste<> ) , mais de préférence nous pourrions concevoir une méthode ou une classe avec un type générique (par exemple Person
Mais si vous vous retrouvez dans cette situation, voici quelques bons conseils.
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 se familiarisent avec le code Java 8, nous pouvons voir que se passe-t-il lors de l'utilisation d'interfaces telles que Fournisseur et Consommateur, et comment la création d'un ErrorMessageCreator local (par exemple) peut être source de confusion et de gaspillage. Jetez un œil à ce package pour voir ce qui est déjà disponible.
[email protected]/* */
Si vous avez vraiment besoin de créer votre propre interface fonctionnelle, marquez-la avec cette annotation comme celle-ci. 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 marquera :
Lorsque vous spécifiez trop de méthodes, il marquera :
Et si vous l'appliquez à une classe au lieu d'une interface, il vous avertira :
Les expressions lambda peuvent être utilisées avec une seule méthode abstraite de n'importe quelle interface, mais ils ne peuvent pas être utilisés dans 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 notre façon de coder. 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 :
Voyez d'un coup d'œil quelles opérations j'ai effectuées
Le débogage est plus facile (bien qu'IntelliJ IDEA fournisse la possibilité de le faire sur une seule ligne. La possibilité de définir des points d'arrêt sur un nombre illimité d'expressions lambda, mais la division en différentes lignes facilite la tâche)
Commentez l'action lorsque je teste des choses
Insérez facilement peek() pour le débogage ou les tests
De plus, à mon avis, c'est plus soigné. 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 les paramètres de formatage pour organiser les opérateurs de points.
Utilisation 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 :
Comparez avec les méthodes d'assistance sur la (relativement) nouvelle classe Objects :
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.
Lors d'une itération sur une collection, utilisez l'API Streams
… ou de nouvelles méthodes de collection 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 strictes, 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.
Je découvre de nouvelles choses chaque jour, et parfois mes préférences changent - par exemple, les références de méthodes, que je détestais et évitais en l'utilisant dans mon code. Maintenant, j'aimerais entendre vos conseils !
Ce qui précède est le contenu des cinq principales compétences de développement de Java 8. Pour plus de contenu connexe, veuillez faire attention au site Web PHP chinois (www.php.cn) !