如何判斷Golang接口是否實現(xiàn)的操作
前言
在看一個底層庫的的時候,看到了一個比較奇怪的寫法,于是乎有了本文。
主要探討兩個問題:
1.利用編譯來判斷Golang接口是否實現(xiàn)
2.延伸出的make和new的區(qū)別
正文
1.利用編譯來判斷Golang接口是否實現(xiàn)
看了一個底層通用鏈接池的庫,有這么一行代碼:
var _ Pooler = new(WeightedRoundRobin)
需要解釋的是:Pooler是一個接口類型。
type Pooler interface {
// ...
}
剛開始看是疑惑的,為什么new了之后是要拋棄調(diào)?
后面發(fā)現(xiàn)這個是為了驗證某某接口是否被實現(xiàn)了?
多看了一些代碼后發(fā)現(xiàn)很多地方有類似這樣的寫法。
至此Get到了。
解釋:如果說次接口沒有被實現(xiàn),那么一方面ide會有紅橫線出現(xiàn),另一方面在編譯的時候會出現(xiàn)報錯。兩方面的提示來保證寫底層代碼的接口是有被實現(xiàn)的。
2.延伸出的make和new的區(qū)別
和小伙伴討論期間,跑出了這么一個問題:“可以使用go test的方式,去_test.go文件中定義一個接口,來判斷就好了。上文判斷會存在浪費內(nèi)存的情況”
這邊兩個點:
1.go test的方式肯定是可行的。
但是并沒法保證程序員會真的記住去執(zhí)行進行檢測(非強制必須走的流程)。但是直接通過前文方式,是會在編譯的時候拋錯的,這個是必須走的流程,所以更推薦前文的方式。
2.new占內(nèi)存?
new:申請了內(nèi)存,但是不會將內(nèi)存初始化,只會將內(nèi)存置零,返回一個指針。
make:申請了內(nèi)存,返回已初始化的結(jié)構(gòu)體的零值。

回到正文,雖然申請了內(nèi)存,但占的內(nèi)存其實并不多,并且在初始化后的一次gc中便會回收。所以還好。
同時也不存在效率問題,編譯型語言,你懂的。
同時驗證一個new和取地址和make的區(qū)別的代碼:
func main() {
a1 := new([]int)
a2:= &[]int{}
a3:= make([]int,0)
fmt.Println(a1,a2,a3,a1==a1)
}
輸出:
&[] &[] [] true
擴展
對于內(nèi)存的占用,今天看到一種寫法。
var _ Tester = (*Test)(nil)
這樣寫和new的區(qū)別在于:new是編譯的時候檢查,這樣寫是運行的時候檢查
補充:Golang接口實現(xiàn)多態(tài)
我就廢話不多說了,大家還是直接看代碼吧~
package main
import (
"fmt"
)
func main() {
user := &User{name: "Chris"}
user.ISubUser = &NormalUser{}
user.sayHi()
user.ISubUser = &ArtisticUser{}
user.sayHi()
}
type ISubUser interface {
sayType()
}
type User struct {
name string
ISubUser
}
func (u *User) sayHi() {
u.sayName()
u.sayType()
}
func (u *User) sayName() {
fmt.Printf("I am %s.", u.name)
}
type NormalUser struct {
}
func (n *NormalUser) sayType() {
fmt.Println("I am a normal user.")
}
type ArtisticUser struct {
}
func (a *ArtisticUser) sayType() {
fmt.Println("I am an artistic user.")
}
//RUN 之后輸出:
I am Chris.I am a normal user.
I am Chris.I am a artistic user.
//重用了sayName和sayHi方法,sayType方法可以多態(tài)來實現(xiàn)。
以上為個人經(jīng)驗,希望能給大家一個參考,也希望大家多多支持腳本之家。如有錯誤或未考慮完全的地方,望不吝賜教。
相關(guān)文章
golang?gorm開發(fā)架構(gòu)及寫插件示例
這篇文章主要為大家介紹了golang?gorm開發(fā)架構(gòu)及寫插件的詳細示例,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步早日升職加薪2022-04-04
go+redis實現(xiàn)消息隊列發(fā)布與訂閱的詳細過程
這篇文章主要介紹了go+redis實現(xiàn)消息隊列發(fā)布與訂閱,redis做消息隊列的缺點:沒有持久化,一旦消息沒有人消費,積累到一定程度后就會丟失,本文給大家介紹的非常詳細,對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2022-09-09
go內(nèi)存緩存BigCache實現(xiàn)BytesQueue源碼解讀
這篇文章主要為大家介紹了go內(nèi)存緩存BigCache實現(xiàn)BytesQueue源碼解讀,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪2023-09-09

