


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!

Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Notepad++7.3.1
Easy-to-use and free code editor

SublimeText3 Chinese version
Chinese version, very easy to use

Zend Studio 13.0.1
Powerful PHP integrated development environment

Dreamweaver CS6
Visual web development tools

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Hot Topics

This article explains Go's package import mechanisms: named imports (e.g., import "fmt") and blank imports (e.g., import _ "fmt"). Named imports make package contents accessible, while blank imports only execute t

This article details efficient conversion of MySQL query results into Go struct slices. It emphasizes using database/sql's Scan method for optimal performance, avoiding manual parsing. Best practices for struct field mapping using db tags and robus

This article explains Beego's NewFlash() function for inter-page data transfer in web applications. It focuses on using NewFlash() to display temporary messages (success, error, warning) between controllers, leveraging the session mechanism. Limita

This article explores Go's custom type constraints for generics. It details how interfaces define minimum type requirements for generic functions, improving type safety and code reusability. The article also discusses limitations and best practices

This article demonstrates creating mocks and stubs in Go for unit testing. It emphasizes using interfaces, provides examples of mock implementations, and discusses best practices like keeping mocks focused and using assertion libraries. The articl

This article details efficient file writing in Go, comparing os.WriteFile (suitable for small files) with os.OpenFile and buffered writes (optimal for large files). It emphasizes robust error handling, using defer, and checking for specific errors.

The article discusses writing unit tests in Go, covering best practices, mocking techniques, and tools for efficient test management.

This article explores using tracing tools to analyze Go application execution flow. It discusses manual and automatic instrumentation techniques, comparing tools like Jaeger, Zipkin, and OpenTelemetry, and highlighting effective data visualization
