web-dev-qa-db-fra.com

paquet protégé alternatif dans kotlin

Dans Java nous avons un modificateur de paquet protégé (par défaut) pour les classes, ce qui permet d'avoir plusieurs classes dans un seul paquet mais d'exposer seulement quelques-unes et de garder la logique encapsulée.

Avec kotlin, cela ne semble pas être le cas, si je veux avoir quelques autres classes qui seront visibles les unes des autres mais pas plus, je dois utiliser un modificateur privé qui limite la visibilité à un seul fichier ... donc essentiellement si vous en aviez 10 classes dans un package et une seule d'entre elles était maintenant publique, vous aurez un énorme fichier avec toutes les classes (et private partout) ...

Est-ce une pratique normale ou existe-t-il un moyen d'obtenir la modularité similaire dans kotlin?

Je ne comprends pas s'ils ont une notion de package pourquoi se sont-ils débarrassés de l'accès protégé aux packages ...

Mise à jour: nous pourrions avoir une visibilité protégée par paquet après tout
voir la discussion ici

visibilitykotlin
44
vach

Kotlin, par rapport à Java, semble s'appuyer dans une moindre mesure sur le modèle de packages (par exemple, la structure des répertoires n'est pas liée aux packages). Au lieu de cela, Kotlin offre internal visibilité , qui est conçu pour une architecture de projet modulaire. En l'utilisant, vous pouvez encapsuler une partie de votre code dans un module séparé.

Ainsi, sur les déclarations de niveau supérieur, vous pouvez utiliser

  • private pour restreindre la visibilité du fichier
  • internal pour restreindre la visibilité du module

À ce stade, il n'y a pas d'autre option pour restreindre la visibilité.

32
hotkey

Comme le souligne @hotkeys, vous pouvez utiliser le mot clé internal dans un module . Je travaille habituellement avec Eclipse et maven et ce n'est pas pratique pour moi de créer ces modules.

Peut-être que pour une pile technologique différente avec IDEA ou Gradle, c'est plus pratique; je ne sais pas parce que je ne les ai jamais utilisés.

L'autre option consiste à placer toutes les classes d'un package dans un seul fichier. Ce n'est pas toujours pratique ou élégant.

Pour moi, la visibilité package est extrêmement utile pour sa valeur documentaire. Je veux savoir quelle interface publique un paquet présente au reste du projet. Je souhaite masquer les classes d'implémentation d'usine, etc.

Donc, même s'il est possible de pirater votre chemin dans Java pour les classes et méthodes de package privé, j'aime toujours utiliser le mot clé package.

J'ai créé un projet avec une seule annotation:

package com.mycompany.libraries.kotlinannotations;

import static Java.lang.annotation.ElementType.CONSTRUCTOR;
import static Java.lang.annotation.ElementType.METHOD;
import static Java.lang.annotation.ElementType.TYPE;
import static Java.lang.annotation.RetentionPolicy.SOURCE;

import Java.lang.annotation.Documented;
import Java.lang.annotation.Retention;
import Java.lang.annotation.Target;

@Documented
@Retention(SOURCE)
@Target({ TYPE, METHOD, CONSTRUCTOR })
/**
 * Use in Kotlin code for documentation purposes. 
 * 
 * Whenever a Kotlin class or method is intended to be accesible at package level only.
 *
 */
public @interface PackagePrivate {

}

Ensuite, je peux utiliser cette annotation dans n'importe quel projet Kotlin.

La deuxième étape, que je n'ai pas encore parcourue, et j'aimerais à un moment donné, consiste à créer une règle PMD pour appliquer cela avec maven (ou tout autre outil de construction d'ailleurs) et également être en mesure de voir violations de la règle dans mon IDE avec le plugin pmd.

Pour le moment, Kotlin n'est pas encore une des langues supportées par pmd (c'est-à-dire avec son propre module). Mais PMD est en développement actif et Kotlin gagne en popularité, il y a donc une chance qu'il soit développé à un moment donné. C'est juste ma meilleure supposition.

5
DPM