Antwoord.

In de programmeertaal Go speelt de organisatie van code door middel van pakketten en het zichtbaarheidssysteem een cruciale rol in modulariteit, hergebruik en encapsulatie van logica.

Geschiedenis van de kwestie

In tegenstelling tot veel klassieke talen met objectgeoriënteerde overerving, is Go vanaf het begin ontworpen rond eenvoudige modules — pakketten met duidelijke regels voor export en import. Dit is een erfenis van de filosofie van minimalisme, eenvoud en strikte controle over afhankelijkheden.

Probleem

Als componenten geen duidelijke zichtbaarheid hebben, ontstaat er chaos in namen, is het moeilijk om afhankelijkheden tussen bestanden te volgen, en neemt het risico op ongewenst gebruik van privé-implementatiedetails toe. Fouten in de organisatie van export kunnen leiden tot moeilijk te debuggen bugs en schending van encapsulatie.

Oplossing

In Go behoort elk bestand verplicht tot een pakket (package naam). Het zichtbaarheidssysteem in Go wordt bepaald door:

Te beginnen met een hoofdletter (geëxporteerd/openbaar)
Te beginnen met een kleine letter (privé)

Alle functies, types, variabelen, constanten en methoden waarvan de naam met een hoofdletter begint, worden geëxporteerd uit het pakket en zijn beschikbaar voor andere pakketten na import. De overige zijn alleen binnen het pakket beschikbaar.

Voorbeeldstructuur:

project/
│
├── main.go          // package main
└── mathutil/
    └── mathutil.go  // package mathutil

Voorbeeldcode:

// mathutil/mathutil.go
package mathutil

// Public - geëxporteerde functie
func Sum(a, b int) int {
    return a + b
}

// private - niet-geëxporteerde functie
func subtract(a, b int) int {
    return a - b
}

// main.go
package main

import (
    "fmt"
    "project/mathutil"
)

func main() {
    fmt.Println(mathutil.Sum(2, 3))      // 5
    // fmt.Println(mathutil.subtract(3,2)) // Compilatiefout! subtract is niet geëxporteerd
}

Belangrijkste kenmerken:

Een eenvoudig en transparant model van export/import
Export wordt alleen bepaald door de eerste letter van de naam — geen sleutelwoorden zijn nodig
Elke map implementeert precies één pakket

Misleidende vragen.

Kun je een variabele of functie die met een kleine letter is gedefinieerd, exporteren via andere mechanismen?

Nee. In Go zijn er geen sleutelwoorden zoals public, private, alles wordt alleen bepaald door de eerste letter van de naam (unicode categorie — hoofdletter).

Kunnen functies van één bestand van een pakket privéfuncties van een ander bestand van hetzelfde pakket gebruiken?

Ja, de zichtbaarheid is beperkt tot het niveau van het pakket, niet het bestand. Alle privé-elementen zijn beschikbaar in alle bestanden van één pakket.

Voorbeeldcode:

// mathutil/helpers.go
package mathutil

func hiddenHelper() int { return 42 }

// mathutil/mathutil.go
package mathutil

func UseHelper() int {
    return hiddenHelper() // beschikbaar!
}

Kun je dezelfde functie of type met dezelfde naam binnen één pakket in verschillende bestanden maken?

Nee, er zal een compilatiefout optreden — binnen een pakket moeten namen uniek zijn, zelfs als ze in verschillende bestanden zijn gedefinieerd.

Typische fouten en anti-patronen

Per ongeluk implementatiedetails exporteren door de naam met een hoofdletter te laten beginnen
Pakketten splitsen in bestanden met dezelfde typenamen
Te veel logica in package main plaatsen (schending van modulariteit)
Export alleen gebruiken voor testdoeleinden (het is beter om een bestand xxx_test.go in hetzelfde pakket te gebruiken)

Voorbeeld uit het leven

Negatief geval

Een groot team plaatst alle hulpfuncties en -types in het pakket util met alles geëxporteerd:

Pluspunten:

Snel gebruik van elke functie zonder onderscheid

Minpunten:

Verlies van encapsulatie (implementatiedetails worden gemakkelijk een afhankelijkheid van andere pakketten)
Moeilijkheid van refactoring en testen

Positief geval

Een team verdeelt de code zorgvuldig in modules volgens bedrijfsterreinen en exporteert alleen de API: