Vertel over de kenmerken van werken met pakketten en zichtbaarheid in Go. Wanneer en hoe moet je exporteerbare en niet-exporteerbare objecten gebruiken?

Antwoord

In Go is de zichtbaarheid van variabelen, functies, structuren en methoden nauw verbonden met de hoofdlettergebruik:

• Een naam die begint met een hoofdletter — het object is exporteerbaar buiten het pakket.
• Een naam die begint met een kleine letter — het object is alleen toegankelijk binnen zijn eigen pakket.

Bestand example.go:

package mypkg

var ExportedVar int    // toegankelijk in andere pakketten
var unexportedVar int  // alleen in mypkg

Bij het importeren van een pakket kan alleen naar exporteerbare objecten worden verwezen.

Best practice:

• Implementatiedetails verbergen, alleen de benodigde types en functies exporteren.
• Gebruik kleine letters voor privé constanten/functies.

Vraag met een val

Vraag: "Kun je een structuur exporteren met niet-exporteerbare velden? Wat gebeurt er als je probeert deze velden in een ander pakket te gebruiken?"

Antwoord: Alleen de structuur met een hoofdletter is exporteerbaar. Alle velden van de structuur die beginnen met een kleine letter, zijn niet toegankelijk buiten het pakket. Pogingen om dergelijke velden van buitenaf te benaderen zal leiden tot een compilatiefout.

Voorbeeld:

// package user

type User struct {
    Name string   // Exporteerbaar veld
    age  int      // Niet toegankelijk buiten pakket user
}

In een ander pakket:

u := user.User{Name: "Ivan"}
u.age = 42 // Compilatiefout: age is niet toegankelijk

Voorbeelden van echte fouten uit de praktijk

---

Verhaal

Gegevensverlies bij JSON-marshalling: In de REST API werd de structuur geëxporteerd, maar de velden werden niet-exporteerbaar gemaakt (met een kleine letter). Hierdoor werd bij de marshal naar JSON deze velden niet inbegrepen, en ontvingen API-gebruikers niet de benodigde informatie.

---

Verhaal

Geen toegang tot benodigde functies: Het team heeft nuttige hulpprogramma's in een apart pakket geplaatst, vergeten hun namen met een grote letter te maken. De functies bleven niet toegankelijk en het was nodig om de interfaces opnieuw te ontwerpen.

---

Verhaal

Naamconflicten bij codegeneratie: Bij het genereren van code in één pakket werden variabelen met dezelfde namen gebruikt, enkel onderscheiden door het hoofdlettergebruik. Een van de scripts hernoemde per ongeluk een exporteerbare constante naar een kleine letter. Hierdoor verloor de applicatie de globale toegang tot deze constante en werd een deel van de functionaliteit niet meer toegankelijk.