转到界面字段

Question

我熟悉一个事实，在Go中，接口定义功能而不是数据。您在接口中放置了一组方法，但是您无法指定实现该接口的任何内容所必需的任何字段。

例如：

// Interface
type Giver interface {
    Give() int64
}

// One implementation
type FiveGiver struct {}

func (fg *FiveGiver) Give() int64 {
    return 5
}

// Another implementation
type VarGiver struct {
    number int64
}

func (vg *VarGiver) Give() int64 {
    return vg.number
}

现在我们可以使用该接口及其实现：

// A function that uses the interface
func GetSomething(aGiver Giver) {
    fmt.Println("The Giver gives: ", aGiver.Give())
}

// Bring it all together
func main() {
    fg := &FiveGiver{}
    vg := &VarGiver{3}
    GetSomething(fg)
    GetSomething(vg)
}

/*
Resulting output:
5
3
*/

现在，您 不能 做的是这样的事情：

type Person interface {
    Name string
    Age int64
}

type Bob struct implements Person { // Not Go syntax!
    ...
}

func PrintName(aPerson Person) {
    fmt.Println("Person's name is: ", aPerson.Name)
}

func main() {
    b := &Bob{"Bob", 23}
    PrintName(b)
}

但是，在研究了接口和嵌入式结构之后，我发现了一种遵循以下方式的方法：

type PersonProvider interface {
    GetPerson() *Person
}

type Person struct {
    Name string
    Age  int64
}

func (p *Person) GetPerson() *Person {
    return p
}

type Bob struct {
    FavoriteNumber int64
    Person
}

由于具有嵌入式结构，Bob拥有Person所拥有的一切。它还实现了PersonProvider接口，因此我们可以将Bob传递到旨在使用该接口的函数中。

func DoBirthday(pp PersonProvider) {
    pers := pp.GetPerson()
    pers.Age += 1
}

func SayHi(pp PersonProvider) {
    fmt.Printf("Hello, %v!\r", pp.GetPerson().Name)
}

func main() {
    b := &Bob{
        5,
        Person{"Bob", 23},
    }
    DoBirthday(b)
    SayHi(b)
    fmt.Printf("You're %v years old now!", b.Age)
}

这是一个演示上面代码的Go
Playground
。

使用这种方法，我可以创建一个定义数据而不是行为的接口，并且可以通过嵌入任何数据而通过任何结构实现该接口。您可以定义与嵌入式数据显式交互且不知道外部结构的性质的函数。并在编译时检查所有内容！（你可以搞砸了，我能看到的唯一方法，将嵌入界面PersonProvider中Bob，而不是一个具体的Person，它会编译并在运行时失败。）

现在，这是我的问题：这是一个巧妙的窍门，还是我应该以不同的方式来做？

Answer 1

这绝对是一个巧妙的把戏。但是，公开指针仍然可以直接访问可用数据，因此，它只为您提供了额外的灵活性，以便将来进行更改。此外，
Go约定不要求您始终将抽象放在数据属性前面 。

综合考虑这些因素，对于给定的用例，我倾向于一个极端或另一极端：要么a）仅仅设置一个公共属性（在适用时使用嵌入），然后传递具体类型，要么b）如果看起来像暴露数据那​​样稍后造成麻烦，请公开获取器/设置器以获得更可靠的抽象。

您将在每个属性的基础上进行权衡。例如，如果某些数据是特定于实现的，或者由于其他原因您希望更改表示形式，则您可能不想直接公开该属性，而其他数据属性可能足够稳定，因此将其公开是绝对的胜利。

将属性隐藏在getter和setter的后面，可以为以后提供向后兼容的更改提供更多的灵活性。假设您某天想更改Person为不仅存储单个“名称”字段，还存储第一/中间/最后/前缀；如果您有方法Name()string和SetName(string)，则可以Person在添加新的更细粒度的方法的同时让界面的现有用户满意。或者，您可能希望在未保存更改的情况下将数据库支持的对象标记为“脏”。您可以在数据更新全部通过SetFoo()方法时执行此操作。

因此：使用getters / setter方法，您可以在维护兼容API的同时更改struct字段，并在属性get /sets周围添加逻辑，因为没有人p.Name = "bob"无需浏览代码就可以这样做。

当类型复杂（并且代码库很大）时，这种灵活性更为重要。如果您有一个PersonCollection，则它可能在内部由sql.Rows，一个[]*Person，一个[]uint数据库ID或其他ID支持。使用正确的界面，您可以节省呼叫者的烦恼，io.Reader使网络连接和文件看起来像样。

一件事：interfaceGo中的s具有独特的属性，您无需导入定义它的包就可以实现它。这可以帮助您避免周期性进口。如果您的接口返回一个*Person，而不只是字符串或其他任何东西，则都PersonProviders必须将包导入Person定义的位置。这可能是好的，甚至是不可避免的；这只是要知道的结果。

但是同样， Go社区没有严格的约定禁止在类型的公共API中公开数据成员
。在给定情况下，将对属性的公共访问作为API的一部分使用是否合理是您的判断，而不是阻止 任何 公开，因为这可能会使以后的复杂化或阻止实现更改，是否合理。

因此，例如，stdlib做类似的事情，让您http.Server使用配置初始化a
并承诺可以使用零bytes.Buffer。这样做自己的事很好，而且，实际上，如果更具体的，数据公开的版本似乎可行，那么我不建议您先将东西抽象掉。这只是要注意权衡。