英文:
Dependency triangle
问题
依赖关系是Go语言中的一个问题,但这是一种新情况:
- 应用程序
A
直接依赖于库B
和C
- 库
B
直接依赖于库C
如果在应用程序 A
的代码中有以下内容:
funcyInstance := &C.FuncyObject{}
B.CleverFunction(funcyInstance)
而在库 B
中有以下内容:
func CleverFunction(arg *C.FuncyObject) {}
就会出现错误:
> 无法将 funcyInstance(类型为 "*A/vendor/github.com/C" 的 FuncyObject)作为参数传递给 B.CleverFunction(类型为 "*B/vendor/github.com/C" 的 FuncyObject)
我正在使用 Glide 作为依赖管理器。
我理解这种依赖关系的配置会导致存在多种类型而不是单一类型(适用于所有库),可能这只是Go语言中的一种反模式。无论如何...如何解决这个问题?
英文:
Dependencies is an issue for Go but this is something new:
- Application
A
directly dependent on librariesB
andC
- Library
B
directly dependent on libraryC
If we have something like this in code of the application A
:
funcyInstance := &C.FuncyObject{}
B.CleverFunction(funcyInstance)
When in lib B
:
func CleverFunction(arg *C.FuncyObject) {}
It raises an error:
> cannot use funcyInstance (type "*A/vendor/github.com/C".FuncyObject) as type "*B/vendor/github.com/C".FuncyObject in argument to B.CleverFunction
I'm using Glide as a dependency manager.
I understand that this configuration of dependencies causes existence of several types instead of a single one (for all library) and possibly it is just an anti pattern for Go. Anyway... How to solve the issue?
答案1
得分: 1
我会为你翻译以下内容:
我会删除B
下面的vendor
文件夹,并将C
放在根目录的vendor
文件夹中(如果我正确理解你的结构,是为了应用程序A
)。
这样,你只需要一个地方存放每种类型的文件。
不确定为什么B
一开始会有一个vendor
文件夹,因为Glide的建议很明确:
http://glide.readthedocs.io/en/latest/vendor/
> 库(没有主要包的代码库)不应该将外部包存储在vendor/文件夹中
和
> 在应用程序(有主要包的代码库)中,顶层只应该有一个vendor/目录。
英文:
I'd remove the vendor
folder below B
, and put C
in the root vendor
folder (for application A
if I am getting your structure correctly).
That way, you only end up with one place for each type.
Not sure why B
would have a vendor
folder in the first place, since Glide's recommendations are clear on this:
http://glide.readthedocs.io/en/latest/vendor/
> Libraries (codebases without a main package) should not store outside packages in a vendor/ folder
and
> In applications (codebases with a main package) there should only be one vendor/ directory at the top level
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论