Risposta.

I pacchetti, le importazioni e le dichiarazioni a livello di file sono alla base della struttura di qualsiasi progetto in Kotlin, e gli sviluppatori spesso si trovano ad affrontare domande sull'organizzazione degli spazi dei nomi e sulla visibilità delle funzioni.

Storia della domanda: Kotlin, continuando le tradizioni di Java, supporta un sistema di pacchetti, ma aggiunge il concetto di dichiarazioni a livello di file, che consente di creare funzioni e proprietà al di fuori delle classi, migliorando la modularità e l'espressività del codice.

Problema: Come organizzare al meglio la visibilità e il punto di accesso a funzioni, proprietà e classi, evitando conflitti di nomi, importazioni duplicate e dipendenze eccessive tra le parti del progetto?

Soluzione:

Per ogni file può essere dichiarato esplicitamente un pacchetto (che corrisponde alla struttura dei file, ma può non corrispondere rigorosamente)
In un singolo file è possibile inserire più classi, funzioni e proprietà di top-level, così come dichiarazioni di oggetti
È possibile importare sia membri singoli che gruppi usando * o alias

Esempio di codice:

package utils

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

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

val PI2 = PI * 2

Caratteristiche chiave:

Gli oggetti e le funzioni a livello di top-level sono disponibili per pacchetto, non richiedono la creazione di istanze di classe
Gli import possono avere alias, il che aiuta a evitare conflitti di nomi
È possibile importare funzioni, proprietà e oggetti di tipo object

Domande trabocchetto.

Possono diversi file con lo stesso nome di pacchetto contenere dichiarazioni con gli stessi nomi di funzioni/proprietà?

Sì, ma ciò porterà a conflitti di nomi durante la compilazione, se non si utilizzano nomi diversi o alias per le importazioni. Le dichiarazioni a livello di file operano all'interno del pacchetto.

La struttura delle cartelle del progetto deve necessariamente corrispondere al pacchetto, come in Java?

No, questo è raccomandato solo per l'organizzazione del codice e la facilità di manutenzione, ma il compilatore consente differenze tra percorsi e pacchetti. Tuttavia, durante il trasferimento del codice o la compilazione tramite strumenti, potrebbero sorgere difficoltà con il logging e la modularità.

È possibile dichiarare più pacchetti all'interno di un singolo file .kt?

No, in un file .kt è possibile dichiarare solo un pacchetto. Mischiare pacchetti porta a errori di compilazione.

Errori tipici e anti-pattern

Mancanza di una convenzione unica di denominazione e struttura pacchetto/cartella
Mettere troppe tematiche diverse in un solo file, mescolando logica di business e funzioni utilitarie
Utilizzare importazioni * in tutti i file invece di importazioni necessarie — riduce la leggibilità, potrebbe portare a conflitti

Esempio dalla vita reale

Caso negativo

Tutte le funzioni ausiliarie di temi diversi sono collocate in un unico pacchetto utils, il file Utility.kt contiene vari metodi business e tecnici:

Pro:

Facile trovare tutte le utilità in un solo posto

Contro:

Il file cresce notevolmente, il contesto delle funzioni si perde, è più difficile da mantenere, complicato il refactoring

Caso positivo

Seguire rigorosamente le convenzioni: ogni pacchetto riflette il dominio, si utilizza il file-level solo per funzioni non appartenenti a nessuna classe, gli alias vengono utilizzati per eliminare duplicati, ogni file è per la sua tematica: