使用多种方法转到接口 - 可接受还是不可接受？

分配给它的函数多于一个的接口有什么问题吗？使用多种方法转到接口 - 可接受还是不可接受？

到处都是我读的，理想情况下接口应该只有一个方法（接口应该以什么名字命名）。但是有没有任何一个坑会有不止一种界面方法？例如，

type FooMgrInterface interface { 
    CreateFoo(hostname string, fooConfig interface{}) (uuid string, err error) 
    DeleteFoo(hostname string, fooID string) (err error) 
    CreateBar(hostname string, barID string, barConfig interface{}) (uuid string, err error) 
    DeleteBar(hostname string, barID string) (err error) 
    AttachBar(hostname string, fooID string, bars []string) (err error) 
    DetachBar(hostname string, barID string) (err error) 
    GetBars(hostname string) (bars []Bar, err error) 
    GetBar(hostname string, barID string) (bar Bar, err error) 
    GetFoo(hostname string, fooID string) (foo Foo, err error) 
    GetFoos(hostname string) (foos []Foo, err error) 
}

如果是这样，上面的接口怎么可以简化或者（可能）分成多个接口？

来源

2017-07-30 nitimalh

没关系，但有10种方法似乎错了。标准库本身有2-3个方法（sync.Locker，sort.Interface），它们并不是组成的，我在代码中也是这样做的。但在你的情况下，你似乎在想着接口的方式。 –

你的代码看起来非常类似于[这个例子]（https://youtu.be/ltqV6pDKZD8?t=29m13s）...观察它大约3分钟，以了解它为什么被认为是反模式。这并不意味着它是错误的。这只是一个类型实现单个接口所需的很多方法，它可能会提出这样的问题：这是一个接口只是为了避免依赖具体类型来传递接口吗？这个接口的所有方法真的需要在这个接口中吗？ –

@ChronoKitsune其更多来自互换性方面。它更多的是实现代理模式。我的应用程序只知道上述在界面中提到的方法。这些方法不应该改变。他们是如何实现的（想想第三方库）。 – nitimalh

寻找灵感，您将看到：

一个。 “原子”接口：Reader,Writer,Closer,Seeker

b。组成接口：ReaderWriter,ReaderWriterSeeker,ReaderSeekerCloser等

golang不会抱怨巨大的接口，它是你和你的同事会抱怨大的单片接口。

我建议将接口分成4个（也许是2个）接口：FooOps,FoosOps,BarOps,BarsOps然后从它们中定义组合接口。

来源

2017-07-30 14:24:57 Ingaz

你说得对。我正在考虑将它分成两个界面和一个为他们组成的界面。感谢您的建议。 – nitimalh

它没有问题，因为语言支持它就好了。

我相信作者正在根据经验提供建筑建议。特别是，如果你的界面有很多方法，你可能在某个地方有错误的抽象。

你可以问自己一些澄清的问题：

多少这个接口的不同实现会不会有？
其中有多少人会有相同的方法实现？
Foos/Bars如何连接到实现者？以某种方式扭转它会更简单吗？例如像在https://golang.org/src/io/io.go

NewFoo(owner FooMgrInterface) *Foo

来源

2017-07-30 03:32:56 jdizzle

使用多种方法转到接口 - 可接受还是不可接受？

回答

相关问题