Antwoord.

Pakketten, imports en file-level declaraties vormen de basisstructuur van elk Kotlin-project, en ontwikkelaars komen vaak vragen tegen over het organiseren van namespaces en de zichtbaarheid van functies.

Achtergrond: Kotlin, in navolging van Java, ondersteunt een pakketsysteem, maar voegt het concept van file-level declaraties toe, waardoor het mogelijk is om functies en eigenschappen buiten een klasse te creëren, wat de modulariteit en expressiviteit van de code verbetert.

Probleem: Hoe organiseer je de zichtbaarheid en de toegangspunten voor functies, eigenschappen en klassen op de handigste manier, terwijl je naamconflicten, dubbele imports en overmatige afhankelijkheden binnen projectdelen vermijdt?

Oplossingen:

Voor elk bestand kan een package expliciet worden gedefinieerd (overeenkomend met de bestandsstructuur, maar hoeft niet strikt overeen te komen)
In één bestand kunnen meerdere klassen, top-level functies en eigenschappen, evenals object-declaraties worden geplaatst
Je kunt afzonderlijke leden importeren, evenals groepen met behulp van * of aliases

Voorbeeld code:

package utils

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

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

val PI2 = PI * 2

Belangrijke kenmerken:

Top-level objecten en functies zijn toegankelijk op basis van package en vereisen geen instantiatie van een klasse
Imports kunnen aliassen krijgen, wat helpt om naamconflicten te voorkomen
Functies, eigenschappen en object-instanties kunnen worden geïmporteerd

Trick vragen.

Kunnen verschillende bestanden met dezelfde package naam dezelfde namen voor functies/eigenschappen bevatten?

Ja, maar dit leidt tot naamconflicten tijdens compilatie, tenzij verschillende namen of aliassen voor imports worden gebruikt. File-level declaraties werken binnen het kader van een package.

Moet de mappenstructuur van het project de package-namen herhalen, zoals in Java?

Nee, dit wordt alleen aanbevolen voor de organisatie van de code en onderhoudsgemak, maar de compiler staat verschillen in paden en packages toe. Maar bij het verplaatsen van code of het bouwen met tools kunnen er problemen ontstaan met logging en modulariteit.

Kun je meerdere packages binnen één .kt bestand declareren?

Nee, in één .kt bestand kan alleen één package worden gedeclareerd. Het mengen van packages leidt tot een compilatiefout.

Veelvoorkomende fouten en anti-patronen

Het negeren van uniforme naamgevings- en structuurafspraken voor pakket/mappen
Het plaatsen van veel verschillende thema's in één bestand, het vermengen van bedrijfslogica en hulpfuncties
Gebruik van *-imports in alle bestanden in plaats van noodzakelijke imports — vermindert leesbaarheid, kan leiden tot conflicten

Voorbeeld uit de praktijk

Negatief geval

Alle hulpfuncties van verschillende thema's bevinden zich in één package utils, het bestand Utility.kt bevat verschillende zakelijke en technische methoden:

Voordelen:

Gemakkelijk om alle hulpprogramma's op één plek te vinden

Nadelen:

Bestand groeit sterk, verliest de context van functies, moeilijker te onderhouden, bemoeilijkt refactoring

Positief geval

Volgt strikt de afspraken: elk pakket weerspiegelt het domein, file-level wordt alleen gebruikt voor functies die niet tot een specifieke klasse behoren, aliassen worden gebruikt om duplicatie te voorkomen, elk bestand voor zijn eigen thema: