


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

Video Face Swap
Swap faces in any video effortlessly with our completely free AI face swap tool!

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





OpenSSL, as an open source library widely used in secure communications, provides encryption algorithms, keys and certificate management functions. However, there are some known security vulnerabilities in its historical version, some of which are extremely harmful. This article will focus on common vulnerabilities and response measures for OpenSSL in Debian systems. DebianOpenSSL known vulnerabilities: OpenSSL has experienced several serious vulnerabilities, such as: Heart Bleeding Vulnerability (CVE-2014-0160): This vulnerability affects OpenSSL 1.0.1 to 1.0.1f and 1.0.2 to 1.0.2 beta versions. An attacker can use this vulnerability to unauthorized read sensitive information on the server, including encryption keys, etc.

Queue threading problem in Go crawler Colly explores the problem of using the Colly crawler library in Go language, developers often encounter problems with threads and request queues. �...

The library used for floating-point number operation in Go language introduces how to ensure the accuracy is...

Backend learning path: The exploration journey from front-end to back-end As a back-end beginner who transforms from front-end development, you already have the foundation of nodejs,...

The difference between string printing in Go language: The difference in the effect of using Println and string() functions is in Go...

This article introduces a variety of methods and tools to monitor PostgreSQL databases under the Debian system, helping you to fully grasp database performance monitoring. 1. Use PostgreSQL to build-in monitoring view PostgreSQL itself provides multiple views for monitoring database activities: pg_stat_activity: displays database activities in real time, including connections, queries, transactions and other information. pg_stat_replication: Monitors replication status, especially suitable for stream replication clusters. pg_stat_database: Provides database statistics, such as database size, transaction commit/rollback times and other key indicators. 2. Use log analysis tool pgBadg

The problem of using RedisStream to implement message queues in Go language is using Go language and Redis...

Two ways to define structures in Go language: the difference between var and type keywords. When defining structures, Go language often sees two different ways of writing: First...
