Alors ce tutoriel est très bien pour ceux qui souhaitent apprendre la syntaxe du langage par contre en aucun cas il ne correspond au titre de l'e-book dont il est un chapitre : "Introduction au langage Kotlin, découvrir les notions avancées de la programmation orientée objet".

En rien l'article ne parle d'OOP et de ses concepts avancés, bien au contraire il met en avant les aspects du langage qui poussent à la programmation procédurale réalisée à partir de structures de données façon C/VB/PL-SQL et je m'explique.

Lorsque vous créez une classe avec des getters et des setters, vous ne faites ni plus ni moins que de créer une structure avec des attributs public déguisés en attributs privés. Fondamentalement, même si c'est au travers d'une méthode, vous permettez à n'importe quelle autre classe de violer l'aspect le plus fondamental de l'OOP : l'encapsulation (je vous invite à suivre les tutos de @Kysofer sur le sujet, c'est un grand gourou du domaine).

D'ailleurs, et pour reprendre l'un de ses cours, l'encapsulation c'est deux composantes :

1. Personne d'autre que la classe ne peut connaître (et encore moins modifier) les données qu'elle contient.
2. Personne d'autre que la classe ne peut connaître le type réel des données qu'elle contient.

Avec un exemple simple, si j'ai cette horreur (du point de vue de l'OOP) :

val name:String = person.getName()`
person.setName("my-name")`

Alors cela revient exactement au même que d'écrire :

val name:String = person.name`
person.name = "my-name"

Cela est tellement la même chose que Kotlin l'assume et génère à la compilation, à partir des getters/setters, le code du second exemple pour permettre l'accès en public aux attributs.

Mais là n'est pas le problème, en effet le vrai problème est que si je venais à changer le type interne de name pour le passer d'une String à un nouveau type, par exemple appelé Name, alors il faudra que je modifie TOUS LES APPELS EFFECTUÉS à getName() car les codes appelant s'attendent à une String, rien n'est encapsulé, rien n'est masqué, a contrario toute la représentation interne fuite à travers les getters/setters et les gens appellent cela innocemment de l'OOP alors que ça n'en est pas du tout : ce sont des struct déguisées en objets.

La solution consiste à n'utiliser que des interfaces car par essence, une interface ne peut pas avoir d'attributs. Alors certes les dérives depuis Java 8 et certains anti-patterns de la programmation fonctionnelle (du point de vue de l'OOP toujours) ont eu tendance à modifier le langage mais dans la pratique, c'est vraiment une très mauvaise idée de mettre des attributs/constantes dans une interface.

Je sais que @Kysofer et @Lenny réfléchissaient à faire des tutos sur l'OOP sur Youtube/PeerTube, j'espère que ce post va les motiver à passer à l'acte. D'ailleurs je partagerai toutes vos vidéos mes chéris :) #Waiting