【极客日常】分享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
}