Pointers 如何干净地初始化golang中相互依赖的两个结构?

Pointers 如何干净地初始化golang中相互依赖的两个结构?,pointers,go,dependency-injection,interface,Pointers,Go,Dependency Injection,Interface,我在当前的项目中遇到了一个问题,我有两个模块,一个实现用于测试目的的接口,另一个只是一个具体的结构,每个模块都依赖于另一个方法 为了解决这种紧张关系,我尝试创建一个顶级“容器”结构,其中包含对依赖结构和接口的引用,然后使用容器结构上的方法,将顶级容器指向另一个结构的指针指定为每个组件结构的成员。我这样做,而不是使用globals,以便能够更好地封装代码以进行测试 然而,无论哪个结构首先被初始化,当第二个结构被初始化时,似乎都看不到另一个结构地址的变化。我不明白为什么,而且我似乎无法按预期完成此功

我在当前的项目中遇到了一个问题,我有两个模块,一个实现用于测试目的的接口,另一个只是一个具体的结构,每个模块都依赖于另一个方法

为了解决这种紧张关系,我尝试创建一个顶级“容器”结构,其中包含对依赖结构和接口的引用,然后使用容器结构上的方法,将顶级容器指向另一个结构的指针指定为每个组件结构的成员。我这样做,而不是使用globals,以便能够更好地封装代码以进行测试

然而,无论哪个结构首先被初始化,当第二个结构被初始化时,似乎都看不到另一个结构地址的变化。我不明白为什么,而且我似乎无法按预期完成此功能

由于实际代码中有许多无关的细节,我创建了这个玩具示例来说明我所说的内容

type container struct {
    r requestor
    a *A
}

type requestor interface {
    Request()
}

type A struct {
    r requestor
}

type R struct {
    a *A
}

func (r R) Request() {
    log.Info("I requested")
    return
}

func (container *container) NewA() *A {
    log.Info("New A received container.r: ", container.r)
    a := &A{
        r: container.r,
    }
    container.a = a
    return a
}

func (container *container) NewR() *R {
    r := &R{
        a: container.a,
    }
    container.r = r
    return r
}

func TestDepResolution(t *testing.T) {
    top := container{}

    top.NewR()
    top.NewA()

    // top.a.r = r

    log.Infof("top: %+v", top)
    log.Infof("R: %+v", top.r)
    log.Infof("A: %+v", top.a)

}
它被设置为一个测试,所以我可以在我的项目中轻松地执行它。输出如下:

=== RUN   TestDepResolution
INFO[0000] New A received container.r: <nil>
INFO[0000] top: {r:0xc000010028 a:0xc00006abc0}
INFO[0000] R: &{a:0xc00006abc0}
INFO[0000] A: &{r:<nil>}
==运行测试解决方案
信息[0000]新收到的容器。r:
信息[0000]顶部:{r:0xc000010028 a:0xc00006abc0}
信息[0000]R:&{a:0xc00006abc0}
信息[0000]A:&{r:}
我期望在调用NewR()后,A的r变量将等于top的r变量,但它似乎没有改变。如果切换NewA()和NewR()的顺序,同样的问题也会出现

因为我在这里使用指针和接口,所以当top的值发生变化时,这些值会被连接起来,但很明显,我一定是误解了什么。我试着用指针玩了很多次,但都没有用


那么为什么这不能像我预期的那样起作用呢?有没有一种方法可以像我建议的那样让这一切顺利进行?还是我对这个问题的想法完全是错误的?我曾试图考虑从模块中提取功能,这样它们就不会相互依赖,我可以完全避免这个问题,但我还没有想出一个好的方法来做到这一点

为了能够以您想要的方式使用指针,您首先需要实际的指针(即非
nil
指针),并且您还需要使用指针间接寻址来“共享”指向值的更新

例如:

type T struct { F string }

a := &T{"foo"} // non-nil pointer
b := a
fmt.Println(b) // output: {"foo"}

*a = T{"bar"}  // pointer indirection
fmt.Println(b) // output: {"bar"}
为了进行比较,以下是您的代码尝试执行的操作:

type T struct { F string }

a := (*T)(nil) // nil pointer
b := a
fmt.Println(b) // output: <nil>

a = &T{"bar"}  // plain assignment
fmt.Println(b) // output: <nil>
因此,您的示例不起作用,因为它没有正确初始化指针,也没有使用指针间接寻址,而是使用简单赋值,只更新目标变量的指针,而不是指向的值


要正确初始化容器,应一步完成:

func NewContainer() *container {
    c := &container{a: &A{}}
    c.r = &R{a: c.a}
    c.a.r = c.r
    return c
}

或者,如果你想分两部分来做,你可以这样做:

func (c *container) NewA() *A {
    log.Println("New A received c.r: ", c.r)
    a := &A{
        r: c.r,
    }
    if c.a != nil {
        *c.a = *a
    } else {
        c.a = a
    }
    return a
}

func (c *container) NewR() *R {
    if c.a == nil {
        c.a = new(A)
    }

    r := &R{
        a: c.a,
    }
    c.r = r
    c.a.r = r
    return r
}

但是,正如您所看到的,初始化如此紧密耦合的依赖关系的多步骤方法可能会变得不必要的复杂和丑陋,即复杂,即非常容易出错。尽量避免



个人说,我会认为这种循环依赖是一种气味,会开始考虑重新设计,但也许那只是我。

为了能够使用指针,就像你想要的那样,你首先需要实际的指针(即不是代码> nIL/COD>指针),你还需要使用指针间接来实现。“共享”指向值的更新

例如:

type T struct { F string }

a := &T{"foo"} // non-nil pointer
b := a
fmt.Println(b) // output: {"foo"}

*a = T{"bar"}  // pointer indirection
fmt.Println(b) // output: {"bar"}
为了进行比较,以下是您的代码尝试执行的操作:

type T struct { F string }

a := (*T)(nil) // nil pointer
b := a
fmt.Println(b) // output: <nil>

a = &T{"bar"}  // plain assignment
fmt.Println(b) // output: <nil>
因此,您的示例不起作用,因为它没有正确初始化指针,也没有使用指针间接寻址,而是使用简单赋值,只更新目标变量的指针,而不是指向的值


要正确初始化容器,应一步完成:

func NewContainer() *container {
    c := &container{a: &A{}}
    c.r = &R{a: c.a}
    c.a.r = c.r
    return c
}

或者,如果你想分两部分来做,你可以这样做:

func (c *container) NewA() *A {
    log.Println("New A received c.r: ", c.r)
    a := &A{
        r: c.r,
    }
    if c.a != nil {
        *c.a = *a
    } else {
        c.a = a
    }
    return a
}

func (c *container) NewR() *R {
    if c.a == nil {
        c.a = new(A)
    }

    r := &R{
        a: c.a,
    }
    c.r = r
    c.a.r = r
    return r
}

但是,正如您所看到的,初始化如此紧密耦合的依赖项的多步骤方法可能会变得不必要的复杂和丑陋,即复杂,即非常容易出错。如果可以,请避免使用它



我个人认为,这种循环依赖性是一种气味,会开始考虑重新设计,但也许那只是我。

一个实现测试目的的接口。“这是你的第一个问题:只为测试目的引入接口是危险的,特别是如果你只想要一个实现”,而仅仅是一个具体的结构,每个都依赖于另一个方法。“考虑重构这个接口测试方法。为什么接口在这里有问题?为什么使用接口进行测试会很危险?我的理解是,这是一开始使用接口的关键原因之一,到目前为止,它对我很有帮助。如果你有相反的观点,我很乐意听到。“一个实现一个用于测试目的的接口”这是你的第一个问题:引入仅用于测试目的的接口是危险的,特别是如果你只打算有一个实现“一个只是一个具体的结构,每个都依赖于另一个方法。”考虑重构这个接口测试方法。为什么接口在这里有问题?为什么使用接口进行测试会很危险?我的理解是,这是一开始使用接口的关键原因之一,到目前为止,它对我很有帮助。如果你有相反的论点,我很高兴听到。啊,非常感谢你为我澄清这一点。我现在可以清楚地看到我在理解指针间接寻址和零指针方面的错误。你的例子很有道理,我喜欢你关于一步初始化的建议。我看到的唯一问题是,如果a和r都成为接口,c.a.r将不会被直接修改