影音體驗是真的強 簡單聊聊iQOO Pad
大公司的好處就是產(chǎn)品線豐富，非常細分化的東西也能給你做出來，例如早先我們看到了新的vivo Pad2，之后我們又在iQOO Neo8 Pro的發(fā)布會上看到了iQOO的首款平板產(chǎn)品iQOO Pad。雖
Go 是一門新興的語言，如果你正在使用它，很可能這不是你的第一門編程語言。
從不同的語言背景轉(zhuǎn)來，你帶來了自己的既有經(jīng)驗和范式。你在以前的語言中習(xí)慣做的事情，在 Go 中可能并不是一個好的方式。
學(xué)習(xí) Go 不僅僅是學(xué)習(xí)一種新的語法。它還涉及到學(xué)習(xí)一種新的程序思維方式。
Go 創(chuàng)始人 Rob Pike 曾經(jīng)說過：“Go 的接口并不是 Java 或 C# 接口的變種，而是更多。它們是大規(guī)模編程和適應(yīng)性強的進化設(shè)計關(guān)鍵?！?span style="display:none">tII28資訊網(wǎng)——每日最新資訊28at.com
圖片
正確使用接口可以帶來簡單性、可讀性和更靈活的代碼設(shè)計。（不正確使用會帶來新的災(zāi)難）
以下是建議了解的基本原則 TOP3:
擁有過多接口的情況叫做：接口污染。當(dāng)你在編寫具體類型之前就開始抽象時，就會出現(xiàn)這種情況。
由于無法預(yù)知需要哪些抽象，因此很容易編寫出過多的接口，而這些接口在日后要么是錯誤的，要么是無用的。
Go 創(chuàng)始人給出了一個很棒的指導(dǎo)方針幫助我們避免接口污染。如下：
不要使用接口設(shè)計，而是發(fā)現(xiàn)它們（Don’t design with interfaces, discover them.） —— Rob Pike
Rob 在這里指出的是：你不需要提前考慮你需要什么抽象。你可以從具體的結(jié)構(gòu)體開始設(shè)計，并在設(shè)計需要時只創(chuàng)建接口。通過這樣做，你的代碼會有機地增長到預(yù)期的設(shè)計。
但我仍然看到人們提前創(chuàng)建接口，因為他們認為他們將來可能需要多個實現(xiàn)。
對于他們，我要說：
圖片
懶惰但要懶惰得好。創(chuàng)建接口的完美時機是當(dāng)你真正需要它的時候，而不是當(dāng)你預(yù)測你需要它的時候。
無用的接口往往只有一個實現(xiàn)。它們只是增加了一個額外的間接層，迫使程序員在他們實際上想要去實現(xiàn)時總是要通過這一層。
一個接口有一個成本：它是你在推理你的代碼時需要記住的一個新概念。正如 Djikstra 所說，一個理想的接口必須是：“一個可以絕對精確的新語義層面?！?span style="display:none">tII28資訊網(wǎng)——每日最新資訊28at.com
所以在創(chuàng)建接口之前問問自己：你有多個接口的實現(xiàn)嗎？我強調(diào)了 “有”，因為 “將有” 意味著你可以預(yù)測未來，而你不能。
在 PHP 項目中看到 10 個方法的接口是很典型的。在 Go 中，接口很小，標準庫中所有接口的平均方法數(shù)是 2。
“越大的接口抽象就越弱”，這是 Go 諺語之一。正如 Rob Pike 所說，這是關(guān)于接口最重要的事情，這意味著接口越小，它就越有用。
一個接口可以有的實現(xiàn)越多，它就越通用。如果你有一個包含大量方法的接口，就很難有多個實現(xiàn)。
你擁有的方法越多，接口就越具體。接口越具體，不同類型的機會就越小，它們可以顯示相同的行為。
io.Reader 和 io.Writer 就是有用接口的一個很好的例子，它們有數(shù)以百計的實現(xiàn)?；蛘呤亲罱?jīng)典的 error 接口，它非常強大，可以在 Go 中實現(xiàn)整個錯誤處理。
記住，你可以從其他接口組合一個接口。這里有一個例子：ReadWriteCloser 由 3 個較小的接口組成。
代碼如下：
type ReadWriteCloser interface { io.Reader io.Writer io.Closer}在傳統(tǒng)語言中，諸如 User、Request 等名詞性接口非常常見。而在 Go 語言中，大多數(shù)接口都有后綴：Reader、Writer、Closer 等。這是因為，在 Go 中，接口暴露了行為，而它們的名稱則指向該行為。
在 Go 中定義接口時，你定義的不是 "某物是什么"，而是 "它提供了什么"-- 是 "行為"，而不是 "事物"！
這就是為什么 Go 中沒有 File 接口，但有Reader 和 Writer：這些都是行為，而 File 是實現(xiàn) Reader 和 Writer 的事物。
《Effective Go》也提到了同樣的觀點：
Go 中的接口提供了一種指定對象行為的方法：如果某個東西可以做到這一點，那么它就可以用在這里。
在編寫接口時，盡量考慮動作或行為。如果你定義了一個名為 "Thing" 的接口，問問自己為什么這個 "Thing" 不是一個結(jié)構(gòu)體。
我經(jīng)常在代碼審查中看到這種情況：很多開發(fā)者在同一個包，既寫了具體的實現(xiàn)，又定義了接口。
生產(chǎn)者定義的接口
但是，也許客戶端并不想使用生產(chǎn)者接口中的所有方法。請記住 "接口隔離原則" 中的一句話："不應(yīng)強迫客戶端實現(xiàn)其不使用的方法"。
下面是一個例子：
package main// ====== producer side// This interface is not neededtype UsersRepository interface { GetAllUsers() GetUser(id string)}type UserRepository struct {}func (UserRepository) GetAllUsers() {}func (UserRepository) GetUser(id string) {}// ====== client side// Client only needs GetUser and// can create this interface implicitly implemented// by concrete UserRepository on his sidetype UserGetter interface { GetUser(id string)}如果客戶端想使用生產(chǎn)者的所有方法，可以使用具體的結(jié)構(gòu)體。因為結(jié)構(gòu)體方法已經(jīng)提供了這些行為。
即使客戶端想要解耦代碼并使用多種實現(xiàn)，他也可以在自己這邊創(chuàng)建一個包含所有方法的接口：
在客戶端定義的接口
由于 Go 中的接口是隱式滿足的，所以這些事情才得以實現(xiàn)?？蛻舳舜a不再需要導(dǎo)入某個接口并編寫實現(xiàn)，因為 Go 中沒有這樣的關(guān)鍵字。
如果實現(xiàn)與接口有相同的方法，那么實現(xiàn)就已經(jīng)滿足了該接口，可以在客戶端代碼中使用。
如果一個方法返回的是接口而不是具體的結(jié)構(gòu)，那么調(diào)用該方法的所有客戶端都將被迫使用相同的抽象。
你需要讓客戶端決定他們需要什么樣的抽象，因為代碼是他們的庭院。
當(dāng)你想使用結(jié)構(gòu)體中的某項功能時，卻因為接口沒有公開它而無法使用，這是很煩人的。這種限制可能是有原因的，但并非總是如此。
下面是一個人為的例子：
type Shape interface { Area() float64 Perimeter() float64}type Circle struct { Radius float64}func (c Circle) Area() float64 { return math.Pi * c.Radius * c.Radius}func (c Circle) Perimeter() float64 { return 2 * math.Pi * c.Radius}// NewCircle returns an interface instead of structfunc NewCircle(radius float64) Shape { return Circle{Radius: radius}}func main() { circle := NewCircle(5) // we lose access to circle.Radius}在上面的示例中，我們不僅無法訪問 circle.Radius，而且每次要訪問它時都需要在代碼中添加類型斷言：
shape := NewCircle(5)if circle, ok := shape.(Circle); ok { fmt.Println(circle.Radius)}因此在設(shè)計上，請遵循 Postel 定律：“發(fā)送時要保守，接受時要寬松”，從方法中返回具體的結(jié)構(gòu)，并選擇接受接口。
結(jié)合現(xiàn)實的代碼，例如原本的代碼是：
// Save writes the contents of doc to the file f.func Save(f *os.File, doc *Document) error但入?yún)⑹?nbsp;f *os.File，這并不靈活，也不便于測試。我們可以通過上面提到的接口方式，改造為如下代碼：
// Save writes the contents of doc to the supplied// Writer.func Save(w io.Writer, doc *Document) error假設(shè)一個場景，你有一個導(dǎo)出名為 User 的類型的軟件包，你實現(xiàn)了 Stringer 接口。
因為出于某種業(yè)務(wù)原因，當(dāng)你打印時，你不希望顯示 email 字段。需要如此實現(xiàn)邏輯：
package userstype User struct { Name string Email string}func (u User) String() string { return u.Name}客戶端的代碼如下：
package mainimport ( "fmt" "pkg/users")func main() { u := users.User{ Name: "腦子進煎魚了", Email: "xxx@gmail.com", } fmt.Printf("%s", u)}這將正確輸出：腦子進煎魚了。
現(xiàn)在，假設(shè)你進行了重構(gòu)，不小心刪除或注釋了 String() 的實現(xiàn)，你的代碼看起來就像這樣：
package userstype User struct { Name string Email string}在這種情況下，您的代碼仍然可以編譯和運行，但輸出結(jié)果將是 {腦子進煎魚了 xxx@gmail.com}。沒有任何程序反饋來提示你出現(xiàn)了問題。編譯器也不會報錯。
這種場景下，為了強制校驗?zāi)硞€類型是否實現(xiàn)了某個接口，我們可以這樣做：
package usersimport "fmt"type User struct { Name string Email string}var _ fmt.Stringer = User{} // User implements the fmt.Stringerfunc (u User) String() string { return u.Name}我們再嘗試一次?，F(xiàn)在如果我們刪除 String() 方法，就會在構(gòu)建時得到如下結(jié)果：
cannot use User{} (value of type User) as fmt.Stringer value in variable declaration: User does not implement fmt.Stringer (missing method String)在該行中，我們試圖將一個空的 User{} 賦值給一個 fmt.Stringer類型的變量。由于 User{} 不再實現(xiàn) fmt.Stringer，我們得到了程序的報錯反饋。
我們在變量名中使用了 _，因為我們并沒有真正使用它，所以不會執(zhí)行真正的分配。
上面我們看到 User 實現(xiàn)了接口。User 和 *User 是不同的類型。因此，如果你想讓 *User 實現(xiàn)它，你可以這樣實現(xiàn)：
var _ fmt.Stringer = (*User)(nil) // *User implements the fmt.Stringer并且通過這種實現(xiàn)，IDE 會顯式提示我們的方法是否有缺失。少了的話會有報錯提示：
圖片
還是非常方便的。當(dāng)然，這個小技巧，不需要對每個實現(xiàn)接口的類型都這樣做，根據(jù)需求對于有必要強校驗的接口即可。
今天這篇文章給大家介紹了六種常見的接口設(shè)計錯誤：創(chuàng)建了太多的接口、方法太多了、沒有編寫行為驅(qū)動的接口、在生產(chǎn)者端編寫接口、正在返回接口、沒有驗證接口合規(guī)性。
我還記得以前看到某個項目里，寫了個接口，20～30 個有待實現(xiàn)的方法。然而他就真的只是一個接口，那么多年過去了也沒有人再去實現(xiàn)這個接口。
當(dāng)然，本文提供的很多接口優(yōu)化建議，也是需要結(jié)合你的實際代碼（業(yè)務(wù)）場景去考慮的。大家各取所需，學(xué)習(xí)之即可。
本文鏈接：http://www.www897cc.com/showinfo-26-98556-0.html六個常見的 Go 接口設(shè)計錯誤
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號