Antwort.

Pakete, Importe und Datei-level Deklarationen bilden die Grundlage der Struktur jedes Kotlin-Projekts, und Entwickler stehen häufig vor Fragen zur Organisation von Namensräumen und der Sichtbarkeit von Funktionen.

Hintergrund: Kotlin unterstützt, weiterhin in der Tradition von Java, ein Paket-System, fügt jedoch das Konzept der Datei-level Deklarationen hinzu, das es ermöglicht, Funktionen und Eigenschaften außerhalb von Klassen zu erstellen, was die Modularität und Ausdruckskraft des Codes verbessert.

Problem: Wie kann die Sichtbarkeit und der Einstiegspunkt zu Funktionen, Eigenschaften und Klassen so bequem wie möglich organisiert werden, um Namenskonflikte, doppelte Importe und übermäßige Abhängigkeiten zwischen Teilen des Projekts zu vermeiden?

Lösung:

Für jede Datei kann ein Package explizit deklariert werden (stimmt mit der Dateistruktur überein, muss aber nicht unbedingt genau übereinstimmen)
In einer Datei können mehrere Klassen, Top-Level-Funktionen und Eigenschaften sowie Object-Deklarationen untergebracht werden
Es können sowohl einzelne Mitglieder als auch Gruppen mit * oder Alias importiert werden

Beispielcode:

package utils

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

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

val PI2 = PI * 2

Schlüsselaspekte:

Top-Level-Objekte und Funktionen sind nach Paket verfügbar, erfordern keine Instanziierung von Klassen
Importe können Aliasnamen haben, um Namenskonflikte zu vermeiden
Funktionen, Eigenschaften und Object-Objekte können importiert werden

Trickfragen.

Können verschiedene Dateien mit demselben Namen des Pakets Deklarationen mit denselben Namen von Funktionen/Eigenschaften enthalten?

Ja, aber dies führt zu Namenskonflikten beim Kompilieren, wenn keine unterschiedlichen Namen oder Aliase für Importe verwendet werden. Datei-level Deklarationen funktionieren innerhalb des Pakets.

Muss die Struktur der Projektverzeichnisse das Paket wie in Java widerspiegeln?

Nein, dies wird nur zur Organisation des Codes und zur Erleichterung der Wartung empfohlen, aber der Compiler erlaubt Unterschiede zwischen Pfaden und Paketen. Allerdings können beim Verschieben von Code oder beim Bauen über Werkzeuge Schwierigkeiten mit Logging und Modularität auftreten.

Kann man mehrere Pakete innerhalb einer .kt-Datei deklarieren?

Nein, in einer .kt-Datei kann nur ein Paket deklariert werden. Das Mischen von Paketen führt zu einem Kompilierungsfehler.

Typische Fehler und Anti-Patterns

Nichteinhaltung einer einheitlichen Namens- und Paket/Verzeichnisstruktur
Zu viele verschiedene Themen in einer Datei vermischen, was die Geschäftslogik und Hilfsfunktionen stört
Verwendung von *-Importen in allen Dateien anstelle von bedarfsgerechten Imports — verringert die Lesbarkeit und kann zu Konflikten führen

Beispiel aus der Praxis

Negativer Fall

Alle Hilfsfunktionen verschiedener Themen sind in einem Paket utils abgelegt, die Datei Utility.kt enthält verschiedene geschäftliche und technische Methoden:

Vorteile:

Alle Utilities an einem Ort leicht zu finden

Nachteile:

Datei wächst stark, Kontext der Funktionen geht verloren, Wartung wird schwieriger, Refactoring wird erschwert

Positiver Fall

Strikte Einhaltung der Vereinbarungen: Jedes Paket spiegelt das Fachgebiet wider, Datei-level wird nur für Funktionen verwendet, die keiner Klasse gehören, Aliase werden verwendet um Duplikate zu beseitigen, jede Datei hat ihr eigenes Thema: