Modificateurs de visibilité dans Kotlin

1. Introduction

Le langage de programmation Kotlin est basé sur la machine virtuelle Java (JVM). En tant que tel, il doit suivre toutes les règles imposées par la JVM, y compris les modificateurs de visibilité.

Cependant, il y a quelques nuances subtiles dans la façon dont le langage implémente ces modificateurs en ce qui concerne le compilateur et la façon dont notre code est structuré. Cet article montrera certaines des similitudes et des différences entre Java et Kotlin à cet égard.

2. Modificateurs de visibilité

Les modificateurs de visibilité sont utilisés pour déterminer quels autres éléments du code ont accès à l'élément en cours de modification. Ils s'appliquent à différents éléments du code, à différents niveaux de portée. La manière dont ces règles sont appliquées peut varier légèrement entre ces différents usages, ce qui peut prêter à confusion au début.

2.1. Visibilité publique

Le modificateur le plus évident est public . C'est probablement le plus fréquemment utilisé dans toute la langue et cela signifie qu'il n'y a aucune restriction supplémentaire sur qui peut voir l'élément en cours de modification.

Contrairement à Java, dans Kotlin, il n'est presque jamais nécessaire de déclarer quoi que ce soit comme public - c'est le modificateur par défaut utilisé si nous n'en déclarons pas un autre. En dehors de cela, cela fonctionne de la même manière dans Kotlin qu'en Java.

Si nous appliquons le modificateur public à un élément de premier niveau - une classe externe ou une fonction ou une variable déclarée directement à l'intérieur d'un package - alors tout autre code peut y accéder. Si nous appliquons le modificateur public à un élément imbriqué - une classe interne, ou une fonction ou une variable à l'intérieur d'une classe - alors tout code pouvant accéder au conteneur peut également accéder à cet élément.

Par exemple:

class Public { val i = 1 fun doSomething() { } } 

La classe Public est accessible de n'importe où dans la base de code entière, «val i» et «fun doSomething ()» sont accessibles depuis tout ce qui peut accéder à Public.

2.2. Visibilité privée

L'autre modificateur qui est utilisé la plupart du temps est privé . Cela a presque exactement le sens opposé de public - cela signifie que personne ne peut y accéder.

En réalité, dans Kotlin cela signifie que seul le code déclaré dans la même portée peut y accéder . Ceci est subtilement différent de Java simplement parce que Kotlin permet plusieurs déclarations de niveau supérieur dans le même fichier - un élément de niveau supérieur privé est accessible par tout le reste dans le même fichier. A part ça, les règles sont les mêmes. Par exemple:

Par exemple:

private class Private { private val i = 1 private val doSomething() { } }

La classe Private n'est accessible qu'à partir du même fichier source, «val i» et «fun doSomething ()» ne sont accessibles que depuis l'intérieur de la classe Private .

2.3. Visibilité protégée

Le modificateur p rotected dans Kotlin signifie qu'il est strictement accessible uniquement par la classe et les sous-classes déclarantes . C'est la même chose que la plupart des gens s'attendent à ce que Java fonctionne, mais subtilement différent de la façon dont Java fonctionne.

En Java, le modificateur protected permet également d'accéder à l'élément à partir de tout autre élément du même package. Par exemple, étant donné le fichier de classe suivant:

class A { protected val i = 1 }

Le fichier suivant fonctionnerait correctement dans Kotlin:

class B : A() { fun getValue() : Int { return i } }

Le fichier suivant fonctionnera en Java mais ne fonctionnera pas dans Kotlin:

class C { fun getValue() : Int { val a = A() return a.i } }

Et ce qui suit ne fonctionnerait ni en Java ni en Kotlin:

class D { fun getValue() : Int { val a = A() return a.i } }

De plus, dans Kotlin, protected devient la visibilité par défaut lorsque nous remplaçons un élément protégé d'une superclasse . Cela peut être explicitement changé en public si vous le souhaitez et c'est la principale fois que nous aurons besoin de déclarer quelque chose comme public explicitement.

2.4. Visibilité par défaut / privée du package

En Java, il existe un modificateur d'accès appelé «package-private» (également appelé «default»). Ceci est utilisé lorsqu'aucun modificateur n'est placé sur l'élément. Cela signifie que n'importe quel code du même package peut y accéder, mais aucun code d'un autre package ne le peut, y compris les sous-classes.

Kotlin n'a actuellement aucun support pour ce modificateur , bien que cela puisse changer à l'avenir. Le raisonnement en est qu'il n'offre aucune protection - n'importe qui peut définir du code dans le même package et accéder à nos éléments, même à partir d'un fichier jar différent.

2.5. Visibilité interne

Kotlin ajoute un nouveau modificateur aux options que Java ne prend pas en charge actuellement - interne . Ce modificateur signifie que tout code déclaré dans le même module qui n'est pas autrement restreint peut accéder à cet élément . (Un module est essentiellement un fichier Jar.)

C'est possible en Java en utilisant des choses comme OSGi, mais ce n'est pas natif pour le moment. Java 9 apportera des concepts qui le rendent plus réalisable en étant capable d'exporter des identifiants publics de manière sélective.

Cela ajoute un énorme avantage pour l'écriture d'API et d'implémentations. Nous pouvons écrire nos interfaces API en tant que public , notre implémentation principale en tant que classes publiques et tout le code de support dont il dépend en tant qu'interne . Cela signifie que le code externe est obligé de passer par l'API et ne peut pas accéder aux internes. Par exemple:

package com.baeldung.modifiers internal class Internal { } class Public { internal val i = 1 internal fun doSomething() { } }

La classe interne n'est accessible que depuis l'intérieur du même module. «Val i» et «fun doSomething ()» ne sont également accessibles que depuis l'intérieur du même module, même si la classe dans laquelle ils se trouvent est accessible de n'importe où.

3. Résumé

Dans l'article, nous avons examiné les modificateurs de visibilité dans Kotlin.

La plupart du temps, les règles de modification de visibilité dans Kotlin fonctionnent de la même manière que ce que nous attendons de Java. Cependant, il existe une différence majeure - qui est l'introduction du périmètre interne - qui est très utile pour les projets plus importants.