Der beste Weg, die Entkopplung in Go zu handhaben, besteht darin, eine ähnliche Struktur in zwei verschiedenen Paketen zu verwenden, aber die untergeordneten Elemente in der Struktur machen es schwierig?

Der beste Weg, die Entkopplung in Go zu handhaben, besteht darin, zwei verschiedene Pakete mit ähnlicher Struktur, aber unterschiedlichen untergeordneten Elementen zu verwenden. Dieser Ansatz trennt den Code effektiv und verbessert die Wartbarkeit und Modularität. Allerdings kann dieser Entkopplungsansatz schwierig werden, wenn die Unterpunkte in der Struktur komplex werden. Erwägen Sie in diesem Fall die Verwendung der Konzepte von Schnittstellen und Polymorphismus, um das Problem zu lösen. Durch die Definition eines gemeinsamen Schnittstellentyps können verschiedene Strukturtypen einheitlich verarbeitet werden, wodurch eine flexiblere Entkopplungsmethode erreicht wird. Dieser Ansatz wird in Go häufig verwendet, um Code erweiterbarer und wiederverwendbar zu machen.

Frageninhalt

Ich bin relativ neu in diesem Bereich und habe eine umfassende Neufassung vorgenommen, um mein Abhängigkeitsdiagramm so weit wie möglich zu reduzieren. Ich bin sehr zufrieden damit, wo ich es bekommen habe, aber es gibt einen Teil, bei dem ich nicht weiß, wie ich am besten damit umgehen soll. Wenn die Antwort „Es wird diese Abhängigkeit zwischen den beiden geben“ lautet, ist das auch in Ordnung, ich suche nur nach einem guten Ansatz, anstatt Wunder zu erwarten.

Also unten habe ich zwei Pakete, a 和 b, und beide haben die gleiche Struktur. Normalerweise könnte man in main das eine in das andere konvertieren, aber jedes hat ein untergeordnetes Element, das ebenfalls eine Struktur ist, was verhindert, dass go dies zulässt, selbst wenn die untergeordneten Elemente dieselbe Signatur haben.

Eine Möglichkeit wäre, in der Struktur von b auf a.tzconfig zu verweisen und ihm eine Abhängigkeit zu geben, aber das ist es, was ich loswerden möchte.

Ich denke, eine andere Möglichkeit besteht darin, eine Schnittstelle zu erstellen und dann den Wert von loc über eine Methode abzurufen. Ich denke, das würde funktionieren, aber ich habe es noch nicht ausprobiert, weil es bedeuten würde, Methoden für etwas zu erstellen, das nur eine Datenstruktur ist (die Die tatsächliche Struktur enthält viele Elemente, die ich der Einfachheit halber hier auf das Wesentliche reduziert habe, was etwas übertrieben erscheint.

Ich könnte tzconfig in ein drittes Modul verschieben, sodass beide auf dieses Modul verweisen, anstatt dass eines auf das andere verweist. Das habe ich mir ausgedacht.

Meine Frage ist also, wie ich von jemandem mit echter Erfahrung am besten mit dieser Situation unterwegs umgehen kann.

Ich sollte erwähnen, dass der Grund dafür, dass sie die Struktur duplizieren, einfach darin liegt, dass ich versuche, die Abhängigkeit zwischen ihnen zu lösen. Der Originalcode enthält nur die Struktur in einem Paket und das andere Paket verweist darauf.

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

Lösung

Meiner Meinung nach ist der Rat von @burakserdar sehr gut und sehr gut für Ihr Szenario geeignet. Ich habe den Code auf diese Weise umgeschrieben.

package common

package common

import "time"

type cfg struct {
    addr string
    loc  tzconfig
}

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

Häufig verwendete Strukturen, Funktionen, Methoden usw. sollten hier platziert werden.

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",
    }
}

Hier wird mit dem a 包相关的特定代码，它继承了 common 包的共享代码，如 import-Teil gezeigt.

Beachten Sie, dass ich die Struktureinbettungsfunktion verwende, um die im common-Paket definierten gemeinsamen Felder abzurufen.

package b

package b

import (
    "dependencies/common"
    "fmt"
)

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

Hier gibt es nichts Besonderes zu erwähnen.

package main

package main

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

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

Hier sollte der Code sehr einfach sein. Ich habe das a 和 b-Paket importiert, um deren Funktionalität zu nutzen.

Ich möchte noch einmal klarstellen, dass dies ein subjektives Thema ist und es daher keine Patentlösung gibt. Für mich sieht es ordentlich und klar aus. Ich würde diesen Ansatz auf jeden Fall wählen. Bitte lassen Sie es mich wissen und vielen Dank!

Das obige ist der detaillierte Inhalt vonDer beste Weg, die Entkopplung in Go zu handhaben, besteht darin, eine ähnliche Struktur in zwei verschiedenen Paketen zu verwenden, aber die untergeordneten Elemente in der Struktur machen es schwierig?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!