【极客日常】分享go开发中wire和interface配合的一些经验
在先前一篇文章中,笔者给大家提到了go语言后端编程可以用wire依赖注入模块去简化单例服务的初始化,同时也可以解决服务单例之间复杂依赖的问题。但实事求是来讲,用wire也是有一些学习成本的,wire在帮助解决复杂依赖的问题同时,也会限定你去用一些特定的编程方式来满足wire的需要,尤其需要你interface给用的更加灵活。
因此今天这篇文章,笔者结合自己的经验,就和大家浅分享下,wire和interface配合的一些经验,让大家以后用wire的时候避免一些坑。
对于wire的build指令而言,build会检查你依赖对象是属于哪种类型,不能出现重复provide某种类型的情况。也就是说,比如你的某个Service需要一个string的member,那这个string就不好单独provide出来,因为其他Service也大概率存在。所以这种情况下,我们需要通过一个string-provider的interface或者struct去对这个string做一个封装,阐明这个参数的独有业务涵义,这样就不会出现依赖重复的情况。
type ThirdPartyClient struct {Client *HttpClientSecret string // 初始情况下,需要提供一个secret参数
}// 一种方式是通过静态config拿,然后wire.Struct给到ThirdPartyClient
type ThirdPartyConfig struct {Secret string
}type ThirdPartyClient struct {Client *HttpClientConfig *ThirdPartyConfig
}func NewThirdPartyClient(httpClient *HttpClient, config *ThirdPartyConfig) *ThirdPartyClient {return &ThirdPartyClient{Client: httpClient,Config: config,}
}// 另一种方式是抽象一个SecretProvider的interface,可以处理动态获取Secret的情况
type ISecretProvider interface {GetSecret() string
}type ThirdPartyClient struct {Client *HttpClientSecretProvider ISecretProvider
}func NewThirdPartyClient(httpClient *HttpClient, secretProvider ISecretProvider) *ThirdPartyClient {return &ThirdPartyClient{Client: httpClient,SecretProvider: secretProvider,}
}
那这里就衍生出新的问题,如果我有很多Secret,一个SecretProvider不够,那怎么办?这个也好办,因为本质上来讲,对于每一个参与wire的实例,我们都需要阐明其的独有业务涵义。也就是说,你得在ISecretProvider基础上,定义IAAASecretProvider、IBBBSecretProvider以及ICCCSecretProvider这种。或者换个例子,我们wire一些缓存模块给业务service,缓存模块就需要这么设计。
type ICache interface {Get(key string) (string, error)Set(key string, value string, expiration time.Duration) error
}type ILocalCache interface {ICache
}type IRemoteCache interface {ICache
}func NewGoCache() ILocalCache {// TODO
}func NewRedisCache() IRemoteCache {// TODO
}
通过这样写,不仅可以区分LocalCache和RemoteCache,满足wire的要求,同时对于其它开发者,也能够清楚知道当前是使用Local和Remote的Cache来做业务逻辑,这样就不会出现误用。