The best way to handle decoupling in Go is to use a similar structure in two different packages, but the children in the structure make it difficult?

The best way to handle decoupling in Go is to use two different packages with similar structure but different subkeys. This approach effectively separates code, improving maintainability and modularity. However, this decoupling approach can become difficult when the sub-items in the structure become complex. In this case, consider using the concepts of interfaces and polymorphism to solve the problem. By defining a common interface type, different structure types can be processed uniformly, thereby achieving a more flexible decoupling method. This approach is widely used in Go to make code more extensible and reusable.

Question content

I'm relatively new to this and have been doing a massive rewrite trying to reduce my dependency graph as much as possible. I'm very happy with where I got it, but there's one part I don't know how best to handle. If the answer is "there will be this dependency between the two" that's fine too, I'm just looking for a good approach rather than expecting miracles.

So below I have two packages, a and b, both of which have the same structure. Normally you could convert one to the other in main , but each has a child which is also a struct, which prevents go from allowing it, even if the children have the same signature.

One way would be to reference a.tzconfig in b's structure and let it have a dependency, but that's what I want to get rid of.

I guess another way would be to create an interface and then get the value of loc via a method, I think this would work, but I haven't tried it yet because it would mean creating methods for something that is just a data structure (the actual structure has A lot of items, which I've reduced here to the essentials for simplicity's sake), this seems like overkill.

I could move tzconfig to a third module so they both reference that module instead of one referencing the other, that's what I thought of.

So my question is, from someone with real experience, what is the best way to handle this situation in go?

I should mention that the reason they duplicate the struct is just because I'm trying to break the dependency between them, the original code just has the struct in one package and the other package references it.

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

IMHO the advice provided by @burakserdar is very good and very suitable for your scenario. I rewrote the code this way.

package common

package common

import "time"

type cfg struct {
    addr string
    loc  tzconfig
}

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

Commonly used structures, functions, methods, etc. should be placed here.

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

Here is specific code related to the a package, which inherits the shared code from the common package, as shown in the import section.

Please note that I use the struct embedding feature to get the common shared fields defined in the package.

package b

package b

import (
    "dependencies/common"
    "fmt"
)

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

There is nothing special worth mentioning here.

package main

package main

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

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

Here, the code should be very simple. I imported the a and b packages to take advantage of their functionality.

I want to clarify again that this is a subjective topic, so there is no magic bullet solution. To me, it looks neat and clear. I would definitely choose this approach. Please let me know and thank you!

The above is the detailed content of The best way to handle decoupling in Go is to use a similar structure in two different packages, but the children in the structure make it difficult?. For more information, please follow other related articles on the PHP Chinese website!