La meilleure façon de gérer le découplage dans Go est d'utiliser une structure similaire dans deux packages différents, mais les enfants dans la structure rendent les choses difficiles ?

La meilleure façon de gérer le découplage dans Go est d'utiliser deux packages différents avec une structure similaire mais des enfants différents. Cette approche sépare efficacement le code, améliorant ainsi la maintenabilité et la modularité. Cependant, cette approche de découplage peut devenir difficile lorsque les sous-éléments de la structure deviennent complexes. Dans ce cas, pensez à utiliser les notions d'interfaces et de polymorphisme pour résoudre le problème. En définissant un type d'interface commun, différents types de structures peuvent être traités uniformément, obtenant ainsi une méthode de découplage plus flexible. Cette approche est largement utilisée dans Go pour rendre le code plus extensible et réutilisable.

Contenu de la question

Je suis relativement nouveau dans ce domaine et j'ai effectué une réécriture massive en essayant de réduire autant que possible mon graphique de dépendances. Je suis très content de l'endroit où je l'ai obtenu, mais il y a une partie que je ne sais pas comment gérer au mieux. Si la réponse est "il y aura cette dépendance entre les deux", c'est bien aussi, je cherche juste une bonne approche plutôt que d'attendre des miracles.

Donc ci-dessous, j'ai deux packages, a 和 b, et ils ont tous deux la même structure. Normalement, vous pouvez convertir l'un en l'autre dans main , mais chacun a un enfant qui est également une structure, ce qui empêche go de l'autoriser, même si les enfants ont la même signature.

Une façon serait de référencer a.tzconfig dans la structure de b et de lui laisser une dépendance, mais c'est ce dont je veux me débarrasser.

Je suppose qu'une autre façon est de créer une interface puis d'obtenir la valeur de loc via une méthode, je pense que cela fonctionnerait mais je ne l'ai pas encore essayé car cela signifierait créer des méthodes pour quelque chose qui n'est qu'une structure de données (le la structure réelle comporte de nombreux éléments, que j'ai réduits ici à l'essentiel par souci de simplicité), ce qui semble un peu exagéré.

Je pourrais déplacer tzconfig vers un troisième module afin qu'ils fassent tous deux référence à ce module au lieu que l'un fasse référence à l'autre, c'est ce que j'ai proposé.

Ma question est donc la suivante, de la part de quelqu'un ayant une réelle expérience, quelle est la meilleure façon de gérer cette situation en go ?

Je dois mentionner que la raison pour laquelle ils dupliquent la structure est simplement parce que j'essaie de rompre la dépendance entre eux, le code d'origine a simplement la structure dans un package et l'autre package y fait référence.

package a

type cfg struct {
    addr                 string
    loc                  tzconfig
}

type tzconfig struct {
    string string
    tz     *time.location `validate:"nodescent"`
}

func getcfg() cfg {
    t, _ := time.loadlocation(`mst`)
    return cfg{
        addr: "abc",
        host: "a.bc.d",
        loc:  config.tzconfig{
            string: "mst",
            tz:     t,
        },
    }
}

package b

type cfg struct {
    addr                 string
    loc                  tzconfig
}

type tzconfig struct {
    string string
    tz     *time.location `validate:"nodescent"`
}

func dosomethingwithconfig(c cfg) {
    fmt.println(c)
}

package main

main() {
     c := a.GetCfg()
     d := b.DoSomethingWithConfig(b.Cg(c))
     fmt.Println(d)
}

Solution

À mon humble avis, les conseils fournis par @burakserdar sont très bons et très adaptés à votre scénario. J'ai réécrit le code de cette façon.

package common

package common

import "time"

type cfg struct {
    addr string
    loc  tzconfig
}

type tzconfig struct {
    string string
    tz     *time.location `validate:"nodescent"`
}

Les structures, fonctions, méthodes, etc. couramment utilisées doivent être placées ici.

package a

package a

import (
    "dependencies/common"
    "time"
)

type cfg struct {
    common.cfg
    host string
}

func getcfg() cfg {
    t, _ := time.loadlocation(`mst`)
    return cfg{
        cfg: common.cfg{
            addr: "abc",
            loc: common.tzconfig{
                string: "mst",
                tz:     t,
            },
        },
        host: "a.bc.d",
    }
}

Ici est montré avec la partie a 包相关的特定代码，它继承了 common 包的共享代码，如 import.

Notez que j'utilise la fonctionnalité d'intégration de structures pour obtenir les champs partagés définis dans le package common.

package b

package b

import (
    "dependencies/common"
    "fmt"
)

func dosomethingwithconfig(c common.cfg) string {
    return fmt.sprint(c)
}

Il n’y a rien de spécial à mentionner ici.

package main

package main

import (
    "dependencies/a"
    "dependencies/b"
    "fmt"
)

func main() {
    c := a.GetCfg()
    d := b.DoSomethingWithConfig(c.Cfg)
    fmt.Println(d)
}

Ici, le code devrait être très simple. J'ai importé le package a 和 b pour profiter de leurs fonctionnalités.

Je tiens à préciser à nouveau qu'il s'agit d'un sujet subjectif et qu'il n'y a donc pas de solution miracle. Pour moi, cela semble net et clair. Je choisirais certainement cette approche. S'il vous plaît laissez-moi savoir et merci!

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!