Java 8 a également été adapté avec un mécanisme qui vous permet d'écrire une programmation moderne en ajoutant un traitement de flux, des types lambda et facultatifs. Mais les programmeurs Java imprègnent-ils une culture d'implémentation moderne?
Cette fois, j'écrirai sur la «programmation immuable» et la «gestion de null» comme méthode d'implémentation moderne.
Il est destiné à l'implémentation d'un serveur d'applications Web. Bien sûr, de nombreuses parties sont appliquées même lors de la mise en œuvre native. Je vais vous expliquer comment écrire Java 8.
Très simplement, il ne se réaffecte pas aux variables. C'est comme programmer avec toutes les finales.
Les gens qui ne l'ont pas encore fait peuvent-ils le faire? Vous pensez peut-être que, mais dans la plupart des cas, les applications Web n'ont pas besoin d'être réaffectées. Parce que le traitement HTTP du navigateur est 1 demande 1 réponse, Vous pouvez le considérer comme une conversion (Request) -> Response. En outre, l'emplacement de gestion de l'état est limité à la session et à la base de données. En d'autres termes, je pense que la plupart d'entre eux peuvent être décrits par un traitement de conversion avec une carte de traitement de flux.
Récemment, il y a eu une tendance à rendre l'infrastructure immuable, et l'infrastructure immuable attire également l'attention. Cela peut être considéré comme une preuve que les avantages d'être immuable sont considérés comme importants.
La valeur de l'objet ne change pas une fois qu'il est créé. En d'autres termes, ce que vous recevez en tant qu'argument de méthode, etc. n'est pas modifié même si vous passez par un autre traitement, il est donc plus facile à déboguer et la visibilité du code est meilleure.
Cela est dû au fait que les variables inconnues telles que celle passée après l'appel de la méthode et le contenu de l'instance ne sont pas réécrites, et la seule nouvelle modification est la variable reçue comme valeur de retour.
On peut dire que les performances sont médiocres et que l'efficacité de la mémoire est réduite en raison du travail de recréation de l'instance entière afin de modifier une variable dans l'objet de classe. Cependant, compte tenu des spécifications actuelles du serveur, il vaut mieux que quelqu'un qui puisse marcher sur un bogue et passer du temps à enquêter et à le corriger, ou écrire le coût humain de la compréhension et du travail sur le code dans une large mesure lors de l'ajout d'une fonction. Dans la plupart des cas, le coût final peut être réduit en améliorant.
Si les performances deviennent un problème, il est plus réaliste de ne corriger que cette partie. Même lors du passage à une logique qui prend en compte les performances, la portée est bien définie, il sera donc souvent possible de la corriger proprement.
Fondamentalement, le processus de conversion comme la carte de flux sera répété.
L'idée de base est que l'objet doit être parfaitement utilisable dès sa naissance. La façon de faire est de transmettre tous les paramètres pour que l'objet existe dans le constructeur.
Java a une mauvaise spécification appelée JavaBeans (d'un point de vue immuable). Il existe un setter, mais il ne doit être utilisé qu'avec des bibliothèques qui fonctionnent selon la spécification Java Beans. (Récemment, plus de bibliothèques peuvent être écrites dans des paramètres privés) Le réglage après avoir fait nouveau crée un objet instable entre nouveau et ensemble. De plus, le fait qu'il existe une méthode définie ne signifie pas qu'une méthode définira quelle valeur à quel moment. Le simple fait d'avoir un setter élargit la portée du débogage.
Si vous le recherchez dans Qiia, il y a beaucoup de gens qui écrivent l'utilisation technique, donc je vais laisser la configuration et l'utilisation détaillées à cela, et je n'écrirai que le cas lorsque vous l'utiliserez avec l'idée d'immuable.
Il fait l'inférence de type et en fait une variable qui ne peut pas être modifiée automatiquement! Dieu immuable!
val x = "hogehoge";
Ajoutez automatiquement des getters pour les variables de champ.
class Hoge {
@Getter
private Integer id;
@Getter
private String name;
}
Générez automatiquement un constructeur qui prend toutes les variables de champ comme arguments.
@AllArgsConstructor
class Hoge {
private Integer id;
private String name;
}
Ajoutez une méthode statique pour créer une instance.
@RequiredArgsConstructor(staticName="of")
class Hoge {
private Integer id;
private String name;
}
Integer id = 1;
String name = "Jojo";
Hoge obj = Hoge.of(id, name)
Vous pouvez obtenir l'effet d'ajouter les annotations @Getter et @AllArgsConstructor ensemble.
C'est OK si vous utilisez toutes les valeurs qui le rendent non substituable.
À partir de là, l'histoire change complètement et est traitée comme nulle. Je pense que la programmation devient monnaie courante dans les langages de programmation modernes, exprimant clairement l'existence et l'inexistence de valeurs.
Il est expliqué en détail dans cet article, donc si vous voulez en savoir plus, veuillez vous y référer.
Les langues non sécurisées nulles ne sont plus des langues héritées
Le plus grand avantage que je pense est que vous pouvez clairement exprimer dans votre code si la variable a toujours une valeur ou aucune valeur (cas nul).
Facultatif a été introduit à partir de Java 8. Par conséquent, le cas qui a toujours une valeur est du même type. S'il y a un cas où il n'y a pas de valeur, il peut être exprimé comme un état où la valeur est contenue dans Facultatif.
Dans la colonne de la table DB, non nul peut être exprimé tel quel, et si nul est possible, il peut être exprimé dans le code source avec Facultatif [type de colonne]. Et vous pouvez forcer le traitement des cas où il n'y a aucune valeur.
Si vous maîtrisez cette programmation, vous n'obtiendrez presque jamais une NullPointerException.
Cependant, malheureusement, je pense qu'il n'y a pas assez de fonctions pour écrire intelligemment.
Des méthodes seront ajoutées pour plus de flexibilité. J'attends personnellement.
Avec le courant facultatif, il n'y a qu'un moyen de séparer le processus de vérification de la sécurité et le processus d'extraction.
Optional o = something;
if(o.isPresent()) {
//Traitement lorsqu'une valeur est saisie
Hoge hoge = o.get(); // <- o.get()N'est pas sûr! !! !!
} else {
//Traitement lorsqu'il n'y a pas de valeur
}
Personnellement, j'aimerais que la méthode optionnelle get soit fondamentalement inutilisable. Pourquoi est-il encapsulé dans Optional lorsque je n'ai pas besoin d'écrire une méthode orElse? De toute évidence, les déclarations et spécifications sont incorrectes.
Mais! Je ne peux pas écrire intelligemment avec Java 8. .. triste.
Pourtant! En Java9, vous pouvez écrire comme ça!
Optional o = something;
o.ifPresentOrElse(
hoge ->{
//Traitement lorsqu'il y a une valeur
print("this is " + hoge)
},
() ->{
//Traitement lorsqu'il n'y a pas de valeur
print("none")
}
);
Ce n'est que lorsqu'il existe une valeur facultative que la valeur est transmise au traitement suivant tel que map! C'est sûr de pouvoir décrire le processus de manière intelligente!
Après avoir étudié Scala, l'idée de programmation fonctionnelle et de programmation immuable est omniprésente, vous pourrez donc peut-être écrire un meilleur code.
Dans tous les langages, je veux être bon en programmation de code pratique qui soit élégant et artistique, pas seulement fonctionnel!
Je veux en savoir plus sur le codage moderne, donc si quelqu'un connaît une meilleure façon de penser, j'aimerais avoir de vos nouvelles.
Recommended Posts