使用多種方法轉到接口 - 可接受還是不可接受？

分配給它的函數多於一個的接口有什麼問題嗎？使用多種方法轉到接口 - 可接受還是不可接受？

到處都是我讀的，理想情況下接口應該只有一個方法（接口應該以什麼名字命名）。但是有沒有任何一個坑會有不止一種界面方法？例如，

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

使用多種方法轉到接口 - 可接受還是不可接受？

回答

相關問題