Odpowiedź.

Pakiety, importy i deklaracje na poziomie pliku leżą u podstaw struktury każdego projektu w Kotlinie, a programiści często zmagają się z pytaniami dotyczącymi organizacji przestrzeni nazw i widoczności funkcji.

Historia problemu: Kotlin, kontynuując tradycje Javy, wspiera system pakietów, ale dodaje koncepcję deklaracji na poziomie pliku, co pozwala tworzyć funkcje i właściwości poza klasami, poprawiając modułowość i wyrazistość kodu.

Problem: Jak zorganizować widoczność i punkt wejścia do funkcji, właściwości i klas w sposób maksymalnie wygodny, unikając konfliktów nazw, podwójnego importu i nadmiarowych zależności między częściami projektu?

Rozwiązanie:

Dla każdego pliku może być jawnie zadeklarowany pakiet (zgodny ze strukturą plików, ale niekoniecznie z nią ścisły)
W jednym pliku można umieścić wiele klas, funkcji i właściwości na najwyższym poziomie, a także deklaracje obiektów
Można importować zarówno pojedyncze człony, jak i grupy za pomocą * lub aliasu

Przykład kodu:

package utils

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

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

val PI2 = PI * 2

Kluczowe cechy:

Obiekty i funkcje na najwyższym poziomie są dostępne przez pakiet, nie wymagają tworzenia instancji klasy
Importy mogą mieć alias, co pomaga uniknąć konfliktów nazw
Można importować funkcje, właściwości i obiekty

Pytania z pułapką.

Czy różne pliki z tą samą nazwą pakietu mogą zawierać deklaracje o tych samych nazwach funkcji/właściwości?

Tak, ale to prowadzi do konfliktu nazw podczas kompilacji, jeśli nie używa się różnych nazw lub aliasów dla importów. Deklaracje na poziomie pliku działają w obrębie pakietu.

Czy struktura katalogów projektu musi powtarzać pakiet, jak w Javie?

Nie, jest to zalecane tylko dla organizacji kodu i łatwości utrzymania, ale kompilator pozwala na różnice między ścieżkami a pakietami. Jednak przy przenoszeniu kodu lub budowaniu za pomocą narzędzi mogą wystąpić trudności z logowaniem i modułowością.

Czy można zadeklarować kilka pakietów w jednym pliku .kt?

Nie, w jednym pliku .kt można zadeklarować tylko jeden pakiet. Mieszanie pakietów prowadzi do błędu kompilacji.

Typowe błędy i antywzorce

Nieprzestrzeganie jednolitej konwencji nazewnictwa i struktury pakiet/katalog
Umieszczanie zbyt wielu różnych tematów w jednym pliku, mieszanie logiki biznesowej z funkcjami pomocniczymi
Używanie importów * we wszystkich plikach zamiast potrzebnych importów — obniża czytelność, może prowadzić do konfliktów

Przykład z życia

Negatywny przypadek

Wszystkie funkcje pomocnicze różnych tematów znajdują się w jednym pakiecie utils, plik Utility.kt zawiera różne metody biznesowe i techniczne:

Zalety:

Łatwo znaleźć wszystkie narzędzia w jednym miejscu

Wady:

Plik znacznie się rozrasta, kontekst funkcji ginie, trudniej utrzymać, utrudniony refaktoring

Pozytywny przypadek

Ścisłe przestrzeganie konwencji: każdy pakiet odzwierciedla obszar domeny, użycie poziomu pliku tylko dla funkcji, które nie należą do jakiejkolwiek klasy, aliasy stosowane w celu eliminacji duplikacji, każdy plik dotyczy swojej tematyki: