Antwoord.

Packages in Go zijn de belangrijkste bouwsteen voor het organiseren van code en het beheren van scopes. Historisch gezien heeft Go een eenvoudig model voor imports en mappenhiërarchie gekozen om programmeren transparant te maken en onduidelijkheden met het oplossen van afhankelijkheden, zoals in C/C++ en Java, te vermijden. Het probleem dat Go oplost, is het creëren van een duidelijke projectstructuur, het voorkomen van naamconflicten en onafhankelijkheid van modules van elkaar.

Probleem: Zonder een uniformere aanpak voor organisatie is het onmogelijk om een applicatie op te schalen, er ontstaat duplicatie, naamconflicten en cyclische afhankelijkheden. Het is belangrijk om de scope van objecten expliciet in de gaten te houden.

Oplossing: Elke map bevat een bestand met een package (package somepackage), de naam van de map en de naam van het package komen overeen volgens best practices. Importeren gebeurt met het sleutelwoord import, en alleen objecten met een hoofdletter aan het begin worden geëxporteerd. Beheer van afhankelijkheden gebeurt via go modules (go.mod).

Voorbeeld van structuur en import:

// 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))
}

Belangrijke kenmerken:

Er is één toegangspunt in het main package (main.main), het is niet mogelijk om main opnieuw te importeren als een bibliotheek
De scope wordt beheerd door hoofdletters (geëxporteerd) en kleine letters (lokaal) in namen
Cyclische imports (cyclische afhankelijkheden) zijn niet toegestaan

Vragen met een twist.

Is het mogelijk om verschillende packages in één map te declareren?

Nee, alle bestanden in een map moeten tot één package behoren.

Worden functies geëxporteerd als ze een naam met een hoofdletter hebben, maar het package met een kleine?

Ja, exporteren hangt alleen af van de eerste letter van de objectnaam (functie, type, variabele), niet van de naam van het package.

Is het mogelijk om een package met een verschillende alias te importeren, en zal dit invloed hebben op de zichtbaarheid van functies?

Ja, dat kan. De alias beïnvloedt alleen de naam waarmee naar het package wordt verwezen, maar verandert niet de scope:

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

Veelvoorkomende fouten en anti-patterns

Schending van package naming: verschillende package namen in één map
Gebruik van onbenoembare imports (import zonder gebruik — compileerfout)
Cyclische afhankelijkheden tussen packages
Logica verplaatsen tussen main/main of util/util

Voorbeeld uit de praktijk

Negatieve case

Een ontwikkelaar plaatst alle functies in één bestand "utils.go" in het main package, zonder de businesslogica in aparte packages te scheiden.

Voordelen:

Snelle prototyping
Lage cognitieve drempel

Nadelen:

Niet leesbaar en niet schaalbaar
Gemakkelijk om de scope te schenden
Verhoogd risico op fouten en duplicatie

Positieve case

Businesslogica, hulpmiddelen, handlers en datamodellen zijn ondergebracht in onafhankelijke packages: mathops, user, storage, api. Importen strikt volgens doel, elke package is afzonderlijk testbaar.