Kotlin a résumé les résultats de l'étude de ce qui a été amélioré en Java, en se concentrant sur «Je ne suis pas satisfait de Java», y compris pourquoi Java est devenu une telle spécification de langage.
・ J'aime Java, mais je n'ai pas utilisé Kotlin pour le moment. (Donc le contenu peut être mince) ・ Le type de langue de Kotlin, la grammaire, etc. sont beaucoup mentionnés ailleurs, donc je ne le mentionnerai pas ici.
Java n'est-il pas le langage le plus convaincant parmi les programmeurs côté serveur? La pensée est sublime et n'accepte pas les débutants. Contrairement à d'autres langages devenus orientés objet au milieu, il ne permet pas d'étranges échappatoires. Concevoir dans ce langage est irrésistible pour les ingénieurs qui aiment penser logiquement, non? (Lol)
Cependant, il y a beaucoup de gens qui n'aiment pas Java car il a ses inconvénients. Et, après tout, très peu de gens veulent l'utiliser en privé (pleurer) Donc, lors de la session d'étude que je fais, j'ai vérifié s'il y avait des personnes utilisant Java en privé, et comme prévu, même une personne sur 15 n'utilisait pas Java (pleurant). Cependant, trois personnes utilisaient Kotlin. À partir de là, je me suis intéressé à Kotlin et j'ai décidé d'enquêter.
Tout d'abord, Java est un endroit agréable pour moi, mais cela ressemble à ceci.
Comment ont-ils été améliorés! ??
Tout d'abord, vous devez savoir pourquoi Java écrit tous les Getters / Setters. Je ne l'ai pas bien compris, mais quand j'ai cherché, il y avait des opinions différentes. ・ Pour masquer les variables membres et les sécuriser -Pour permettre le suivi des modifications des variables membres (faire de la place pour le traitement) Je n'étais pas convaincu par ceux-ci, et il semblait que je pouvais le définir en public, mais c'est la bonne réponse à laquelle je suis finalement arrivé. -Les variables de membre ne peuvent pas être remplacées dans les sous-classes! Alors enveloppez-le dans une méthode et remplacez cette méthode si vous voulez que la sous-classe change son comportement.
C'est maintenant une propriété en C #, ruby, swift. Vous n'avez donc pas besoin d'écrire Getter / Setter. Les propriétés peuvent être remplacées dans les sous-classes. Vous pouvez également abstraire et forcer l'implémentation dans des sous-classes.
Il semble que ce soit la seule méthode adoptée uniquement en Java. Les exceptions levées par une méthode doivent être explicitement déclarées dans le cadre de la syntaxe de la méthode, et l'appelant doit la gérer ou la lancer ci-dessus.
public FileInputStream(String name)
throws FileNotFoundException
Cela présente les avantages suivants:
De nombreux langages et mécanismes traitent les exceptions comme à l'exécution, et vous ne savez pas quel type d'exceptions se produira jusqu'à ce qu'elles se produisent réellement, et si elles peuvent provenir de ce processus en premier lieu. Surtout dans le cas de Java, puisque vous pouvez comprendre les types d'exceptions, vous pouvez vous attendre à beaucoup de récupération d'exceptions. [Source: Rethinking inspection exceptions](http://qiita.com/Kokudori/items/0fe9181d8eec8d933c98#java%E3%81%AE%E6%A4%9C%E6%9F%BB%E4%BE%8B%E5 % A4% 96)
Cependant, cela est maintenant considéré comme une erreur et n'a pas été incorporé dans d'autres langages orientés objet qui représentent C #.
Les clauses de rattrapage sans signification sont produites en masse et réduisent en fait la qualité du programme. Source: L'évolutivité des exceptions vérifiées
Les exceptions vérifiées ne sont plus appliquées et la gestion des exceptions par l'appelant n'est plus appliquée.
Se produit si vous utilisez des variables avant la création de l'instance.
//Erreur d'exécution pour Java
String s = null;
s.length(); // java.lang.NullPointerException
Cela ne peut pas être aidé, non? J'ai pensé, mais les langues modernes ont un mécanisme pour garantir cela. Référence: les langues non sécurisées nulles ne sont plus des langues héritées
Dans Kotlin, s'il peut être Null, il est spécifié au moment de la déclaration, et s'il peut être Null, cela entraînera une erreur de compilation à moins qu'il ne soit vérifié au préalable.
//Variable?Null peut être défini dans la déclaration ci-jointe.?Un réglage nul n'est pas possible sans lui.
val s: String? = null
s.length //Erreur de compilation: only safe (?.) or non-null
↓
//OK écriture
val s:String? = null
if (s != null){
s.length // OK
}
Comme vous le savez, Java a huit types primitifs (booléen, char, byte, short, int, long, float, double), qui ont des classes wrapper pour les types d'objet.
Pourquoi existe-t-il des types primitifs de variables? Java a pris nombre de ses idées du C ++. Les variables de type primitif en font partie. Et j'étais heureux d'avoir visé l'afflux de programmeurs C ++ existants en incorporant cela. De plus, le type primitif semble avoir l'avantage d'une vitesse de traitement élevée. Référence: types primitifs considérés comme nuisibles
Référence: faille inconnue dans Java
-Il est nécessaire d'utiliser correctement le traitement tout en sachant si la variable manipulée est un type primitif ou un type d'objet.
⇒ [Exemple] Les types primitifs peuvent être comparés à ==, les types d'objets utilisent .equals (), etc.
-Afin de passer une variable de type primitif à une méthode qui prend un type d'objet comme argument, il est nécessaire de la convertir une fois en type d'objet, ce qui gaspille de la mémoire.
Il n'y a pas de types primitifs dans Kotlin. (Cependant, on peut dire qu'une partie de la commodité du type primitif a été perdue.)
C'est tout, mais pour le moment, j'avais l'impression que les parties que je ne pourrais pas dire personnellement étaient presque améliorées.
Si j'ai quelque chose à voir avec Java, j'adorerais utiliser Kotlin.
Recommended Posts