41 votes

Kotlin: const val vs val

Je comprends dans Kotlin const val est utilisé pour déclarer des constantes et des val est pour les propriétés en lecture seule. Cependant, je me demande dans le cas suivant, qui est plus approprié à utiliser.

Supposons que j'ai un fragment qui a besoin d'une clé à utiliser pour saveInstanceState et restoreInstanceState. Je me demande lequel des 2 options suivantes est la meilleure:

Option 1:

class MyFragment {
    private val MY_KEY = "my_key"
    ...
}

Option 2:

private const val MY_KEY = "my_key" // declared in the same file.

class MyFragment {
    ...
}

Je préfère le #l'option 2 car il est clairement indiqué que MY_KEY est une constante, et la valeur est déterminée au moment de la compilation. Toutefois, puisqu'il déclaré sur le haut niveau, il en coûte une classe c'est à dire MyFragmentKt (à supposer que le nom de fichier MyFragment.kt) à être créé dans le code java compilé. Dans #l'option 1, pas de classe supplémentaire est généré et bien qu' MY_KEYs'valeur va être affecté à l'exécution et non constante, qui ne fait aucune différence dans la façon dont il est utilisé dans ce cas précis.

Ainsi, bien que personnellement, je préfère #option 2, mon analyse me fait penser à #l'option 1 n'est pas le pire, si ce n'est mieux. Je me demande comment les autres les développeurs de réfléchir à ce sujet et si il y a d'autres avantages d' #option 2 que je n'ai pas pensé. Merci.

24voto

Marko Topolnik Points 77257

Chaque fois que vous écrivez une expression lambda (non en ligne), vous avez créé une autre classe. Par rapport à cela, la création d'une classe unique pour contenir les déclarations de niveau supérieur semble mineure.

De plus, si tout ce que vous avez au niveau supérieur est une déclaration constante, elle sera insérée dans chaque site d'utilisation (par spécification) afin que la classe propriétaire elle-même devienne non référencée et donc ciblable par la minimisation de ProGuard. Il n'apparaîtra probablement pas dans votre APK de production.

16voto

Moira Points 5673

Il n'y a pas seulement une différence sémantique entre les deux options.

Option 1 (val à l'intérieur de la classe) est un champ d'instance.

Option 2: (niveau supérieur const val) est d'un niveau supérieur "statique" membre (en gros, depuis static n'existe pas dans Kotlin.)

C'est pourquoi vous avez un MyFragmentKt classe de produit: haut-niveau membres sont compilés dans une classe du nom [Filename]Kt.

Je considère une troisième option:

class MyFragment {
    companion object {
        private const val MY_KEY = "my_key"
    }
}

De cette façon, MY_KEY (de Java) un static membre de l' MyFragment de la classe, puisque JvmStatic est déduit pour const variables. Il y aura un Companion classe générée (mais il sera vide).

Depuis votre approche originale a été un champ à l'intérieur de la classe j'ai envie de l' companion object/static constante serait peut-être préférable.

Plus sur companion objects vs Java static

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X