Odpowiedź.

Pakiety w Go to podstawowy blok budulcowy do organizacji kodu i zarządzania zasięgiem. Historycznie Go przyjęło prosty model importów i hierarchii folderów, aby uczynić programowanie przejrzystym i uniknąć niejasności z rozwiązywaniem zależności, tak jak miało to miejsce w C/C++ i Java. Problem, który Go rozwiązuje, polega na tworzeniu zrozumiałej struktury projektu, zapobieganiu konfliktom nazw i niezależności modułów od siebie.

Problem: Bez jednolitego podejścia do organizacji niemożliwe jest skalowanie aplikacji, co prowadzi do dublowania kodu, konfliktów nazw i cyklicznych zależności. Ważne jest, aby na bieżąco monitorować zasięg obiektów.

Rozwiązanie: Każdy katalog zawiera plik z pakietem (package somepackage), nazwa katalogu i nazwa pakietu powinny się zgadzać zgodnie z najlepszymi praktykami. Importuje się za pomocą słowa kluczowego import, a eksportowane stają się tylko obiekty zaczynające się od dużej litery. Zarządzanie zależnościami – przez go modules (go.mod).

Przykład struktury i importu:

// internal/mathops/add.go
package mathops

func Add(a, b int) int {
    return a + b
}

// main.go
package main

import (
    "fmt"
    "myservice/internal/mathops"
)

func main() {
    fmt.Println(mathops.Add(2, 3))
}

Kluczowe cechy:

Jedyny punkt wejścia w pakiecie main (main.main), niemożność ponownego importowania main jako biblioteki
Zakres zarządzany jest przez wielkie litery (eksportowane) i małe litery (lokalne) w nazwach
Cyclic imports (cykliczne zależności) są zabronione

Pytania z pułapkami.

Czy można w jednym katalogu zadeklarować kilka różnych pakietów?

Nie, wszystkie pliki w katalogu muszą należeć do jednego pakietu.

Czy funkcje staną się eksportowane, jeśli mają nazwę zaczynającą się dużą literą, a pakiet jest nazwany małą?

Tak, eksport zależy tylko od pierwszej litery nazwy obiektu (funkcji, typu, zmiennej), a nie od nazwy pakietu.

Czy można importować pakiet z różnym aliasem, i czy wpłynie to na widoczność funkcji?

Tak, można. Alias wpływa tylko na to, jakim imieniem odwołujemy się do pakietu, ale nie zmienia zakresu widoczności:

import mymath "myservice/internal/mathops"
mymath.Add(1,2)

Typowe błędy i antywzorce

Naruszenie nazewnictwa pakietów: różne nazwy pakietów w jednym katalogu
Użycie nieużywanych importów (import bez użycia – błąd kompilacji)
Cyliczne zależności między pakietami
Przeniesienie logiki między main/main lub util/util

Przykład z życia

Negatywny przypadek

Programista umieszcza wszystkie funkcje w jednym pliku "utils.go" w pakiecie main, nie wydzielając logiki biznesowej do oddzielnych pakietów.

Zalety:

Szybkie prototypowanie
Niski próg kognitywny

Wady:

Trudne do odczytania i skalowania
Łatwo naruszyć zakres widoczności
Zwiększone ryzyko błędów i dublowania

Pozytywny przypadek

Logika biznesowa, narzędzia, obsługiwacze, modele danych są wydzielone do niezależnych pakietów: mathops, user, storage, api. Importy ściśle według przeznaczenia, każdy pakiet testowany oddzielnie.