Réponse.

Les packages, les importations et les déclarations au niveau du fichier sont à la base de la structure de tout projet en Kotlin, et les développeurs se heurtent souvent à des questions d'organisation de l'espace de noms et de visibilité des fonctions.

Historique de la question : Kotlin, poursuivant les traditions de Java, prend en charge le système de packages, mais ajoute le concept de déclarations au niveau du fichier, ce qui permet de créer des fonctions et des propriétés en dehors des classes, améliorant ainsi la modularité et l'expressivité du code.

Problème : Comment organiser la visibilité et le point d'entrée dans les fonctions, propriétés et classes de manière aussi pratique que possible, en évitant les conflits de noms, les importations redondantes et les dépendances excessives entre les parties du projet ?

Solution :

Pour tout fichier, un package peut être explicitement déclaré (il coïncide avec la structure des fichiers, mais peut ne pas correspondre strictement)
Dans un même fichier, plusieurs classes, des fonctions et propriétés au niveau supérieur, ainsi que des déclarations d'objets peuvent être placées
On peut importer soit des membres individuels, soit des groupes à l'aide de * ou d'alias

Exemple de code :

package utils

import kotlin.math.*
import model.User as UserModel

fun sum(a: Int, b: Int) = a + b

val PI2 = PI * 2

Caractéristiques clés :

Les objets et fonctions au niveau supérieur sont accessibles par package, ne nécessitent pas de création d'instances de classe
Les importations peuvent avoir des alias, ce qui aide à éviter les conflits de noms
On peut importer des fonctions, des propriétés et des objets-objets

Questions piège.

Différents fichiers avec le même nom de package peuvent-ils contenir des déclarations avec les mêmes noms de fonctions/propriétés ?

Oui, mais cela entraînera un conflit de noms lors de la compilation, sauf si des noms différents ou des alias pour les importations sont utilisés. Les déclarations au niveau du fichier fonctionnent dans le cadre du package.

La structure des répertoires d'un projet doit-elle obligatoirement répéter le package, comme en Java ?

Non, c'est recommandé uniquement pour l'organisation du code et la facilité de maintenance, mais le compilateur autorise la différence entre les chemins et les packages. Cependant, lors du déplacement de code ou de la construction à l'aide d'outils, des difficultés peuvent survenir avec la journalisation et la modularité.

Peut-on déclarer plusieurs packages dans un même fichier .kt ?

Non, dans un fichier .kt, on ne peut déclarer qu'un seul package. Le mélange des packages entraîne une erreur de compilation.

Erreurs typiques et anti-patrons

Non-respect d'une convention uniforme de nommage et de structure package/répertoire
Trop de thématiques différentes dans un seul fichier, mélangeant la logique métier et les fonctions utilitaires
Utilisation de l'importation * dans tous les fichiers au lieu d'importations selon le besoin — réduit la lisibilité, peut entraîner des conflits

Exemple de la vie réelle

Cas négatif

Toutes les fonctions d'assistance de différentes thématiques sont situées dans un même package utils, le fichier Utility.kt contient diverses méthodes métier et techniques :

Avantages :

Facile de trouver toutes les utilitaires à un seul endroit

Inconvénients :

Le fichier devient très volumineux, le contexte des fonctions est perdu, plus difficile à maintenir, le refactoring est compliqué

Cas positif

On suit strictement les conventions : chaque package reflète un domaine d'application, le niveau de fichier est utilisé uniquement pour les fonctions n'appartenant à aucune classe, des alias sont utilisés pour éliminer la duplication, chaque fichier pour sa thématique :