Disons que j'ai un service qui communique avec GitHub via l'API pour créer et modifier des référentiels.
La liste des fonctions pourrait ressembler à quelque chose comme ci-dessous.
Chaque requête apportée à l'API a plusieurs parties mobiles, donc je la divise en plusieurs fonctions cette mise en page a 2 problèmes - Tout est dans un gros fichier appelé Étant donné que tout cela se trouve dans le même package GO, le nom doit être unique. J'ai donc des noms d'espace de noms avec l'action et le contexte (E.G. merci!
github_service.go et je ne sais pas comment le scinder. devrait-il être dans des sous-répertoires plus petits tels que Services / github / update_service.go ? En général, comment organise-on des services tels que celui-ci dans un projet simple (par exemple, une utilitaire de ligne de commande )
Findgithubrepositoryl () au lieu de URL () ). devrait être sous un package séparé? . Mais alors comment partageraient-ils des aides communs?
3 Réponses :
Vous pouvez organiser votre projet avec ce Structure
J'ai créé un référentiel avec cette structure, vous pouvez le cloner et utiliser c'est comme un modèle. J'espère que j'ai aidé :)
Il y a plusieurs solutions à cela.
Ceci peut également donner aux gestionnaires un moyen d'accéder à des fonctionnalités ou à des variables courantes. Vous pouvez créer une structure de base avec celles et l'intégrer à toutes les structures de manutention.
Merci! L'approche de structure semble être un moyen d'imiter les classes traditionnelles fournies par d'autres langages de l'OOP tels que Ruby et Python, non?
Il s'agit d'une approche davantage de type OO avec l'isolement de l'espace de noms de noms et de la capacité de transmettre des services communs spécifiques aux ressources à chaque mise en œuvre. J'utilise cela souvent et conserve des services de backend spécifiques à des ressources dans la structure pour le gestionnaire.
Merci! Serait-il possible de regrouper tout par trouver () au lieu de la ressource ( utile , base, etc ...)? Et voudriez-vous avoir un exemple de travail de cela que vous pourriez partager? Apprécier l'aperçu.
Vous pouvez le regrouper comme ça, parfois, cela a du sens tout en l'écrivant. Pensez à la façon dont vous trouverez ce que vous avez besoin d'un mois plus tard, lorsque vous le lisez. Je ne suis pas au courant d'un exemple ouvert qui utilise ce type de structure. Il semble plus approprié pour un CLI, comme 'Kubectl Obtenir des pods'.
Commencez par un paquet et une fois que vous avez identifié une sous-partie cohérente et fermée: déplacez-la à son propre package.