跑分安卓第一！Redmi K60至尊版8月發布！盧偉冰：目標年度性能之王
8月5日消息，Redmi K60至尊版將于8月發布，在此前舉行的戰略發布會上，官方該機將搭載搭載天璣9200+處理器，安兔兔V10跑分超177萬分，是目前安卓陣營最高的分數
Go 是一門新興的語言，如果你正在使用它，很可能這不是你的第一門編程語言。
從不同的語言背景轉來，你帶來了自己的既有經驗和范式。你在以前的語言中習慣做的事情，在 Go 中可能并不是一個好的方式。
學習 Go 不僅僅是學習一種新的語法。它還涉及到學習一種新的程序思維方式。
Go 創始人 Rob Pike 曾經說過：“Go 的接口并不是 Java 或 C# 接口的變種，而是更多。它們是大規模編程和適應性強的進化設計關鍵。”
圖片
正確使用接口可以帶來簡單性、可讀性和更靈活的代碼設計。（不正確使用會帶來新的災難）
以下是建議了解的基本原則 TOP3:
擁有過多接口的情況叫做：接口污染。當你在編寫具體類型之前就開始抽象時，就會出現這種情況。
由于無法預知需要哪些抽象，因此很容易編寫出過多的接口，而這些接口在日后要么是錯誤的，要么是無用的。
Go 創始人給出了一個很棒的指導方針幫助我們避免接口污染。如下：
不要使用接口設計，而是發現它們（Don’t design with interfaces, discover them.） —— Rob Pike
Rob 在這里指出的是：你不需要提前考慮你需要什么抽象。你可以從具體的結構體開始設計，并在設計需要時只創建接口。通過這樣做，你的代碼會有機地增長到預期的設計。
但我仍然看到人們提前創建接口，因為他們認為他們將來可能需要多個實現。
對于他們，我要說：
圖片
懶惰但要懶惰得好。創建接口的完美時機是當你真正需要它的時候，而不是當你預測你需要它的時候。
無用的接口往往只有一個實現。它們只是增加了一個額外的間接層，迫使程序員在他們實際上想要去實現時總是要通過這一層。
一個接口有一個成本：它是你在推理你的代碼時需要記住的一個新概念。正如 Djikstra 所說，一個理想的接口必須是：“一個可以絕對精確的新語義層面。”
所以在創建接口之前問問自己：你有多個接口的實現嗎？我強調了 “有”，因為 “將有” 意味著你可以預測未來，而你不能。
在 PHP 項目中看到 10 個方法的接口是很典型的。在 Go 中，接口很小，標準庫中所有接口的平均方法數是 2。
“越大的接口抽象就越弱”，這是 Go 諺語之一。正如 Rob Pike 所說，這是關于接口最重要的事情，這意味著接口越小，它就越有用。
一個接口可以有的實現越多，它就越通用。如果你有一個包含大量方法的接口，就很難有多個實現。
你擁有的方法越多，接口就越具體。接口越具體，不同類型的機會就越小，它們可以顯示相同的行為。
io.Reader 和 io.Writer 就是有用接口的一個很好的例子，它們有數以百計的實現。或者是最經典的 error 接口，它非常強大，可以在 Go 中實現整個錯誤處理。
記住，你可以從其他接口組合一個接口。這里有一個例子：ReadWriteCloser 由 3 個較小的接口組成。
代碼如下：
type ReadWriteCloser interface { io.Reader io.Writer io.Closer}在傳統語言中，諸如 User、Request 等名詞性接口非常常見。而在 Go 語言中，大多數接口都有后綴：Reader、Writer、Closer 等。這是因為，在 Go 中，接口暴露了行為，而它們的名稱則指向該行為。
在 Go 中定義接口時，你定義的不是 "某物是什么"，而是 "它提供了什么"-- 是 "行為"，而不是 "事物"！
這就是為什么 Go 中沒有 File 接口，但有Reader 和 Writer：這些都是行為，而 File 是實現 Reader 和 Writer 的事物。
《Effective Go》也提到了同樣的觀點：
Go 中的接口提供了一種指定對象行為的方法：如果某個東西可以做到這一點，那么它就可以用在這里。
在編寫接口時，盡量考慮動作或行為。如果你定義了一個名為 "Thing" 的接口，問問自己為什么這個 "Thing" 不是一個結構體。
我經常在代碼審查中看到這種情況：很多開發者在同一個包，既寫了具體的實現，又定義了接口。
生產者定義的接口
但是，也許客戶端并不想使用生產者接口中的所有方法。請記住 "接口隔離原則" 中的一句話："不應強迫客戶端實現其不使用的方法"。
下面是一個例子：
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)}如果客戶端想使用生產者的所有方法，可以使用具體的結構體。因為結構體方法已經提供了這些行為。
即使客戶端想要解耦代碼并使用多種實現，他也可以在自己這邊創建一個包含所有方法的接口：
在客戶端定義的接口
由于 Go 中的接口是隱式滿足的，所以這些事情才得以實現。客戶端代碼不再需要導入某個接口并編寫實現，因為 Go 中沒有這樣的關鍵字。
如果實現與接口有相同的方法，那么實現就已經滿足了該接口，可以在客戶端代碼中使用。
如果一個方法返回的是接口而不是具體的結構，那么調用該方法的所有客戶端都將被迫使用相同的抽象。
你需要讓客戶端決定他們需要什么樣的抽象，因為代碼是他們的庭院。
當你想使用結構體中的某項功能時，卻因為接口沒有公開它而無法使用，這是很煩人的。這種限制可能是有原因的，但并非總是如此。
下面是一個人為的例子：
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)}因此在設計上，請遵循 Postel 定律：“發送時要保守，接受時要寬松”，從方法中返回具體的結構，并選擇接受接口。
結合現實的代碼，例如原本的代碼是：
// Save writes the contents of doc to the file f.func Save(f *os.File, doc *Document) error但入參是 f *os.File，這并不靈活，也不便于測試。我們可以通過上面提到的接口方式，改造為如下代碼：
// Save writes the contents of doc to the supplied// Writer.func Save(w io.Writer, doc *Document) error假設一個場景，你有一個導出名為 User 的類型的軟件包，你實現了 Stringer 接口。
因為出于某種業務原因，當你打印時，你不希望顯示 email 字段。需要如此實現邏輯：
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)}這將正確輸出：腦子進煎魚了。
現在，假設你進行了重構，不小心刪除或注釋了 String() 的實現，你的代碼看起來就像這樣：
package userstype User struct { Name string Email string}在這種情況下，您的代碼仍然可以編譯和運行，但輸出結果將是 {腦子進煎魚了 xxx@gmail.com}。沒有任何程序反饋來提示你出現了問題。編譯器也不會報錯。
這種場景下，為了強制校驗某個類型是否實現了某個接口，我們可以這樣做：
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}我們再嘗試一次。現在如果我們刪除 String() 方法，就會在構建時得到如下結果：
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{} 不再實現 fmt.Stringer，我們得到了程序的報錯反饋。
我們在變量名中使用了 _，因為我們并沒有真正使用它，所以不會執行真正的分配。
上面我們看到 User 實現了接口。User 和 *User 是不同的類型。因此，如果你想讓 *User 實現它，你可以這樣實現：
var _ fmt.Stringer = (*User)(nil) // *User implements the fmt.Stringer并且通過這種實現，IDE 會顯式提示我們的方法是否有缺失。少了的話會有報錯提示：
圖片
還是非常方便的。當然，這個小技巧，不需要對每個實現接口的類型都這樣做，根據需求對于有必要強校驗的接口即可。
今天這篇文章給大家介紹了六種常見的接口設計錯誤：創建了太多的接口、方法太多了、沒有編寫行為驅動的接口、在生產者端編寫接口、正在返回接口、沒有驗證接口合規性。
我還記得以前看到某個項目里，寫了個接口，20～30 個有待實現的方法。然而他就真的只是一個接口，那么多年過去了也沒有人再去實現這個接口。
當然，本文提供的很多接口優化建議，也是需要結合你的實際代碼（業務）場景去考慮的。大家各取所需，學習之即可。
本文鏈接：http://www.tebozhan.com/showinfo-26-98556-0.html六個常見的 Go 接口設計錯誤
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 秒殺系統架構解析：應對高并發的藝術
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號