第三方配置结构的封装

时间:2019-07-25 13:59:20

标签: go struct interface dependencies decoupling

我正在执行Go项目,在这里我利用一些相当大的第三方客户端库与某些第三方REST API进行通信。我的目的是将内部代码API与这些特定的依赖项分离开来。

在我的代码中从这些库中解耦特定方法很简单,因为我只需要功能的一个子集,并且能够抽象出用例。因此,我在代码中引入了一种新类型,该类型实现了我的特定用例。然后底层的实现依赖于第三方的依赖关系。

configuration structs是我无法理解如何找到良好去耦的地方。通常,我正在使用的客户端库提供这种形式的一些功能

createResourceA(options *ResourceAOptions) (*ResourceA, error)
createResourceB(options *ResourceBOptions) (*ResourceB, error)

其中*ResourceA*ResourceB是相应资源在创建后的服务器端配置。

不同的options是具有大量字段,嵌套结构等的资源的大型配置结构。通常,这些配置可以容纳我的应用程序所需的更多选项,但最终总的来说重叠很大。

因为我想避免我的内部代码必须导入特定的依赖项才能访问我想封装它们的配置结构。

我目前的封装方法是定义自己的配置结构,然后将其用于配置第三方依赖项。举一个简单的例子:

import a "github.com/client-a"

// MyClient implements my use case functions
type MyClient struct{}

// MyConfiguration wraps more or less the configuration options
// provided by the client-a dependency
type MyConfiguration struct{
  Strategy StrategyType
  StrategyAOptions *StrategyAOptions
  StrategyBOptions *StrategyBOptions
}

type StrategyType int
const (
  StrategyA StrategyType = iota
  StrategyB
)

type StrategyAOptions struct{}
type StrategyBOptions struct{}


func (c *MyClient) UseCaseA(options *MyConfiguration) error {
  cfg := &a.Config{}
  if (options.Strategy = StrategyA) {
    cfg.TypeStrategy = a.TypeStrategyXY
  }
  ...
  a.CreateResourceA(cfg)
}


如示例使用此方法所示,我可以封装第三方配置结构,但是我认为此解决方案不能很好地扩展。我已经遇到了一些示例,其中我基本上是在代码中重新实现依赖关系的类型,只是将依赖关系抽象化。

如果我的方法普遍错误,我在这里寻找也许更复杂的解决方案和/或一些见解。

我的进一步研究:

我调查了struct embedding,是否可以帮助我。但是,由于配置包含非平凡的成员,因此我最终还要在调用代码中导入依赖项以填充字段。

由于通常的准则似乎是Accept interfaces return structs,因此我尝试使用此方法找到一个好的解决方案。但是在这里我也可以得到一个相当大的接口,并且在运行中,标准库配置结构似乎无法通过接口使用。如果在Go中将配置隐藏在接口后面是一种好习惯,那么我找不到明确的声明。

总结一下:

我想知道如何从第三方库中提取配置结构,而不必最终在代码中重新定义相同的数据类型。

1 个答案:

答案 0 :(得分:0)

一件非常简单的事情-重新定义包装程序包中所需的结构类型?

我要去的很新,所以这可能不是最好的选择。

package myConfig

import a "github.com/client-a"

type aConfig a.Config

那么您只需要导入myConfig包

import "myConfig"
// myConfig.aConfig is actually a.Config
myConfig.aConfig

不确定由于这不是真正的去耦,所以不确定是否有很大帮助,但是至少您不需要在每个地方都导入“ github.com/client-a”

相关问题