Struct 在已键入的结构上转到结构类型

Struct 在已键入的结构上转到结构类型,struct,go,Struct,Go,我在package xyz中有一个名为Service的结构,多个api包装器(Api1,Api2)将使用该结构作为基础。我希望有人使用这个包来调用每个API的方法,比如:xyz.Api1.MethodA(..)和xyz.Api2.MethodB(..) 现在我正在做这样的事情 type struct api1 { *Service } var Api1 *api1 func init() { Api1 = &api1{ &Service{

我在
package xyz
中有一个名为
Service
的结构,多个api包装器(
Api1
Api2
)将使用该结构作为基础。我希望有人使用这个包来调用每个API的方法,比如:
xyz.Api1.MethodA(..)
xyz.Api2.MethodB(..)

现在我正在做这样的事情

type struct api1 {
    *Service
}

var Api1 *api1

func init() {
    Api1 = &api1{
        &Service{
            ...
        }
    }
}

func (a *api1) MethodA {
    ...
}
我不喜欢这个,因为它看起来像很多样板。我更希望Api1是一个服务结构,但每个服务都有不同的方法,所以我认为这是不可能的,除非我能做
类型服务Api1{…}


有没有另一种方法可以让用户调用类似于
xyz.Api1.MethodA(..)
,而不必为每个api创建新的结构类型,也不需要太多的样板文件?

不使用全局变量,只需创建两个新类型,让用户决定如何使用它们:

type API1Service struct {
    *Service
    api1Param1 int
    // etc.
}

func NewAPI1Service(api1Param1 int) *API1Service { /* ... */ }

// methods on API1Service

type API2Service struct {
    *Service
    api2Param1 int
    // etc.
}

func NewAPI2Service(api2Param1 int) *API2Service { /* ... */ }

// methods on API2Service
然后,您的用户就可以这样做了

api := xyz.NewAPI1Service(42)
api.MethodA()
// etc.

为什么不把
api1
api2
分开?此外,API上的方法是否以任何方式使用
服务
?是的,有些方法会调用
服务
上的方法。如果我要将
api1
api2
分离到它们自己的包中,我可以参考父包中的
Service
?或者我想问题是导入是否可以使用相对路径,例如,
导入“./xyz”
?出于各种原因,建议永远不要使用相对路径,但是的,您可以使用它。另一种可能是创建两个新的导出类型,
API1Service
API2Service
,在它们上定义方法,并让用户实例化它们并按自己的意愿使用<代码>服务甚至不应该是公共的,公开创建任何api然后让用户实例化的函数。谢谢