我熟悉一个事实,在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,它会编译并在运行时失败。)
PersonProvider
Bob
Person
现在,这是我的问题:这是一个巧妙的窍门,还是我应该以不同的方式来做?
这绝对是一个巧妙的把戏。但是,公开指针仍然可以直接访问可用数据,因此,它只为您提供了额外的灵活性,以便将来进行更改。此外, Go约定不要求您始终将抽象放在数据属性前面 。
综合考虑这些因素,对于给定的用例,我倾向于一个极端或另一极端:要么a)仅仅设置一个公共属性(在适用时使用嵌入),然后传递具体类型,要么b)如果看起来像暴露数据那样稍后造成麻烦,请公开获取器/设置器以获得更可靠的抽象。
您将在每个属性的基础上进行权衡。例如,如果某些数据是特定于实现的,或者由于其他原因您希望更改表示形式,则您可能不想直接公开该属性,而其他数据属性可能足够稳定,因此将其公开是绝对的胜利。
将属性隐藏在getter和setter的后面,可以为以后提供向后兼容的更改提供更多的灵活性。假设您某天想更改Person为不仅存储单个“名称”字段,还存储第一/中间/最后/前缀;如果您有方法Name()string和SetName(string),则可以Person在添加新的更细粒度的方法的同时让界面的现有用户满意。或者,您可能希望在未保存更改的情况下将数据库支持的对象标记为“脏”。您可以在数据更新全部通过SetFoo()方法时执行此操作。
Name()string
SetName(string)
SetFoo()
因此:使用getters / setter方法,您可以在维护兼容API的同时更改struct字段,并在属性get /sets周围添加逻辑,因为没有人p.Name = "bob"无需浏览代码就可以这样做。
p.Name = "bob"
当类型复杂(并且代码库很大)时,这种灵活性更为重要。如果您有一个PersonCollection,则它可能在内部由sql.Rows,一个[]*Person,一个[]uint数据库ID或其他ID支持。使用正确的界面,您可以节省呼叫者的烦恼,io.Reader使网络连接和文件看起来像样。
PersonCollection
sql.Rows
[]*Person
[]uint
io.Reader
一件事:interfaceGo中的s具有独特的属性,您无需导入定义它的包就可以实现它。这可以帮助您避免周期性进口。如果您的接口返回一个*Person,而不只是字符串或其他任何东西,则都PersonProviders必须将包导入Person定义的位置。这可能是好的,甚至是不可避免的;这只是要知道的结果。
interface
*Person
PersonProviders
但是同样, Go社区没有严格的约定禁止在类型的公共API中公开数据成员 。在给定情况下,将对属性的公共访问作为API的一部分使用是否合理是您的判断,而不是阻止 任何 公开,因为这可能会使以后的复杂化或阻止实现更改,是否合理。
因此,例如,stdlib做类似的事情,让您http.Server使用配置初始化a 并承诺可以使用零bytes.Buffer。这样做自己的事很好,而且,实际上,如果更具体的,数据公开的版本似乎可行,那么我不建议您先将东西抽象掉。这只是要注意权衡。
http.Server
bytes.Buffer