Réponse.

Les packages en Go sont le principal bloc de construction pour l'organisation du code et la gestion des portées. Historiquement, Go a choisi un modèle d'importation et une hiérarchie de dossiers simples pour rendre la programmation transparente et éviter les incertitudes liées à la résolution des dépendances, comme on le voit en C/C++ et Java. Le problème que Go résout est la création d'une structure de projet claire, la prévention des conflits de noms et l'indépendance des modules les uns par rapport aux autres.

Problème : Sans approche unifiée pour l'organisation, il est impossible d'évoluer l'application, ce qui entraîne des duplications, des conflits de noms, des dépendances cycliques. Il est important de surveiller explicitement la portée des objets.

Solution : Chaque répertoire contient un fichier avec le package (package somepackage), le nom du répertoire et le nom du package coïncident selon les meilleures pratiques. L'importation se fait via le mot-clé import, et seuls les objets commençant par une lettre majuscule sont exportés. La gestion des dépendances se fait via les modules Go (go.mod).

Exemple de structure et d'importation :

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

Caractéristiques clés :

Un seul point d'entrée dans le package main (main.main), impossible de réimporter main en tant que bibliothèque
La portée est gérée par la maiuscule (exporté) et la minuscule (local) des noms
Les imports cycliques ne sont pas permis

Questions piège.

Peut-on déclarer plusieurs packages différents dans un même répertoire ?

Non, tous les fichiers dans un répertoire doivent appartenir à un seul package.

Les fonctions deviendront-elles exportées si elles ont un nom avec une majuscule, alors que le package est nommé avec une minuscule ?

Oui, l'exportation dépend uniquement de la première lettre du nom de l'objet (fonction, type, variable), et non du nom du package.

Peut-on importer un package avec un alias différent, et cela influence-t-il la portée des fonctions ?

Oui, c'est possible. L'alias n'influe que sur le nom utilisé pour accéder au package, mais ne change pas la portée :

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

Erreurs typiques et anti-patterns

Violation du nommage des packages : noms de packages différents dans un même répertoire
Utilisation d'importations non déclarées (importation sans utilisation – erreur de compilation)
Dépendances cycliques entre les packages
Transfert de logique entre main/main ou util/util

Exemple de la vie réelle

Cas négatif

Le développeur place toutes les fonctions dans un seul fichier "utils.go" dans le package main, sans distinguer la logique métier en packages séparés.

Avantages :

Prototypage rapide
Faible seuil cognitif

Inconvénients :

Illisible et non évolutif
Risque de violer la portée
Risque accru d'erreurs et de duplications

Cas positif

La logique métier, les utilitaires, les gestionnaires, les modèles de données sont extraits dans des packages indépendants : mathops, user, storage, api. L'importation se fait strictement par destination, chaque package est testé séparément.