Les packages internes de Go peuvent-ils réellement encapsuler les détails de mise en œuvre ?

Packages internes dans Go

Les règles rigides de visibilité des packages de Go visent à garder les surfaces d'API bien définies et distinctes. Cependant, il n'est pas possible d'encapsuler les détails d'implémentation dans des packages plus petits sans les exposer à des consommateurs externes lorsque le projet se développe.

Une solution à ce dilemme a été proposée dans Go 1.4 : introduire des packages « internes ».

Importation de packages internes

Un package "interne" ne peut être importé que par d'autres packages au sein de la même arborescence. Cette règle visait à créer une séparation claire entre les packages publics et internes, empêchant ainsi l'exposition accidentelle des détails d'implémentation internes.

Exemple

Tenter d'importer un package interne depuis l'extérieur de son arborescence parent entraîne une erreur :

import (
    "runtime/internal/atomic"
    "runtime/internal/sys"
)

Erreur :
imports runtime/internal/atomic : utilisation du package interne non autorisé

Pouvez-vous accéder aux fonctions internes ?

La question de l'utilisation des fonctions internes dans un package principal découle du désir de garder les détails d'implémentation isolés. Malheureusement, il ne s'agit pas d'un cas d'utilisation prévu pour les packages internes.

Ce qu'il faut retenir

Encapsuler les détails d'implémentation dans les packages internes n'est pas pratique dans Go. Envisagez plutôt de refactoriser votre base de code en modules distincts avec des interfaces publiques bien définies. Cette approche s'aligne sur l'accent mis par Go sur des limites claires de l'API et favorise la maintenabilité et l'extensibilité du code.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!