解开这种依赖传递

Golang小白一枚，正在不断学习积累知识，现将学习到的知识记录一下，也是将我的所得分享给大家！而今天这篇文章《解开这种依赖传递》带大家来了解一下##content_title##，希望对大家的知识积累有所帮助，从而弥补自己的不足，助力实战开发！

我正在尝试找出如何从我的服务中删除传递依赖项。

我们将我的服务命名为 servicea。

servicea 依赖于libraryb。 libraryb 依赖于libraryc。因此，servicea 传递依赖于libraryc。让我解释一下如何...

在本例中，libraryc 恰好是 ozzo-validation 库。在此库中，有一个名为 errors 的类型，它被定义为 map[string]error。您可以在 https://github.com/go-ozzo/ozzo-validation/blob/v3.6.0/error.go 上看到它，但这里仅供参考：

package validation

type errors map[string]error

// implement the error interface
func (es errors) error() string {
    // implementation omitted for brevity
}

请注意，类型 errors 实现了 error 接口。

正如我已经写过的，libraryb 依赖于 libraryc，ozzo-验证。 libraryb对ozzo-validation的使用是这样的：

package web

// error responds to a request with an error object and the specified status
func error(w http.responsewriter, err error, status int) {
    // implementation omitted for brevity
    errors, ok := err.(validation.errors)
    if ok {
        for key, err1 := range errors {
            // implementation omitted for brevity
        }
        // implementation omitted for brevity
    }
    // implementation omitted for brevity
}

这就是整个用法。 libraryb 导入 ozzo-validation，以便 libraryb 可以执行类型断言、errors、ok := err.(validation.errors)，以及然后在地图上进行范围，for key, err1 := 范围错误。

我的服务 servicea 不知道 libraryb 依赖于 ozzo-validation。 servicea 也想使用 ozzo-validation，但需要使用较新的版本，因为较新的版本具有更多功能和一些重要的错误修复。这个较新的版本是 v4.3.0。 servicea 调用 ozzo-library 中的一些方法，这些方法返回 validation.errors 实例，并将该实例传递给 libraryb 的 web.error 函数作为err 参数错误。

这就是乐趣的开始。由于 servicea 传入 v4.3.0 validation.errors 实例，而 libraryb 是针对 v3.6.0 validation.errors 进行类型断言，因此即使类型定义完全正确，类型断言也会失败v3.6.0 和 v4.3.0 中相同。

如何解决这个问题？

我确实可以访问libraryb的源代码并且可以更改它。我可以轻松升级 libraryb 以使用 ozzo-validation v4.3.0，但这会使这种传递耦合永久化。我宁愿完全删除这种传递耦合。

我尝试将 libraryb 中的类型断言更改为

errors, ok := err.(map[string]error)

因为最终这就是实例，map[string]error，但编译器不喜欢这样，因为 map[string]error 没有实现 error 接口。

有什么方法可以让我自己的对象实现 error 并且也是可范围的，以便我可以将 v4.3.0 `validation.errors 包装在某种接口或会破坏这种传递耦合的东西中？

我该怎么做才能打破这种紧密的传递性耦合？

解决方案

如果担心 libraryb 的向后兼容性，则不能仅将 libraryb 中的 ozzo-validation 升级到 v4。因为如果有一个serviced使用libraryc@v3和libraryb，这样的升级会破坏serviced。

幸运的是，在 go 模块的帮助下，libraryb 可以导入 v3 和 v4，并对这两个版本进行类型断言。

package web

import (
 validationv3 "github.com/go-ozzo/ozzo-validation/v3"
 validationv4 "github.com/go-ozzo/ozzo-validation/v4"
)

// Error responds to a request with an error object and the specified status
func Error(w http.ResponseWriter, err error, status int) {
    // Implementation omitted for brevity
    errorsv3, ok := err.(validationv3.Errors)
    if ok {
        for key, err1 := range errorsv3 {
            // Implementation omitted for brevity
        }
        // Implementation omitted for brevity
    }
    // Implementation omitted for brevity


    errorsv4, ok := err.(validationv4.Errors)
    if ok {
        for key, err1 := range errorsv4 {
            // Implementation omitted for brevity
        }
        // Implementation omitted for brevity
    }
    // Implementation omitted for brevity

}

以上就是《解开这种依赖传递》的详细内容，更多关于的资料请关注golang学习网公众号！