Golang中的“Mutual”包导入

发布时间：2020-12-16 09:26:14 所属栏目：大数据来源：网络整理

导读：是否可以在Golang中执行类似“相互”包导入的操作？让我们说例如我有两个包,A和B,功能AFunc和BFunc,BFunc2 package Aimport "B"func AFunc() { //do stuff but also use B.BFunc()} – package Bimport "A"func BFunc() { //do foo}func BFunc2() { //do di

是否可以在Golang中执行类似“相互”包导入的操作？

让我们说例如我有两个包,A和B,功能AFunc和BFunc,BFunc2

package A
import "B"

func AFunc() {
    //do stuff but also use
    B.BFunc()
}

–

package B
import "A"

func BFunc() {
    //do foo
}

func BFunc2() {
    //do different stuff but also use
    A.AFunc()
}

有没有办法实现这一点,而不使用第三个包作为“桥梁”？

编辑：
为了澄清这个问题,这当然不可能通过“简单地”来实现,因为编译器将抛出导入循环不允许错误.问题是,是否有更清洁或更成熟的方法来解决这个问题,然后建立一个“桥梁包”？

解决方法

interface应该是一个明显的答案：只要两个软件包都提出具有一组通用函数的接口,它就允许：

> packageB使用A中的函数(导入A)
> packageA从B调用函数而不必导入B：所有需要传递的B实例实现A中定义的接口：这些实例将视图作为A对象.
从这个意义上讲,packageA忽略了packageB的存在.

这也在“Cyclic dependencies and interfaces in golang”的评论中说明.

If package X accepts/stores/calls methods on/returns types defined package Y,but doesn’t actually access Y‘s (non-method) functions or variables directly,X can use an interface that the type in Y satisfies rather than actually importing Y.

avoiding dependencies with interfaces in general,you can see how,say,the 07002 doesn’t depend on 07003 for the 07004 even though its functions can work on Files. (It just defines 07005,etc.,and 07006.)

例如,io在其Copy() function中接受一个’Writer'(可以是一个文件或其他知道如何写的文件),并完全忽略os(.File)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!