Go 代码的惯用组织方式

huangapple go评论83阅读模式
英文:

Idiomatic Go Code Organization

问题

注意:我看到了其他与这个主题相关的问题,但没有一个解决了手头的问题。

我在整理我的Go代码时遇到了困难。我正在编写一个守护进程,我希望能够在文件之间进行逻辑上的代码拆分。

假设我有3个文件,main.go

package main

func main() {
    GlobalFunc()

    commonFunc()

    var svr server.Server
    server.OtherFunc()
}

server.go

package main

type Server struct {
    name string
    ip   string
}

func GlobalFunc() {

}

func (s *Server) OtherFunc() {
    commonFunc()
}

common.go

package main

func commonFunc() {

}

我希望能够将GlobalFunc()调用为server.GlobalFunc(),以显示它是“server模块”的一部分。但在上面的示例中似乎不可能实现这一点。

我可以创建一个名为server的子目录,将server.go放在其中,并将其改为package server。但问题在于我似乎无法在主包和server包之间共享common.go。我理解为什么会这样,而且这似乎也不是一个好主意。

所以我在这里是否遗漏了一些简单的东西,从而使问题变得更加复杂?

谢谢!

英文:

Note: I've seen other questions related to this topic but none that address the issue at hand.

I'm struggling to organize my Go code. I'm writing a daemon and I would like to split the code logically between files.

Say I have 3 files, main.go:

package main

func main() {
    GlobalFunc()

    commonFunc()

    var svr server.Server
    server.OtherFunc()
}

server.go:

package main

type Server struct {
    name string
    ip string
}

func GlobalFunc() {

}

func (s *Server) OtherFunc() {
    commonFunc()
}

and common.go:

package main

func commonFunc() {

}

I would like to be able to call GlobalFunc() as server.GlobalFunc() to show it's part of the "server module". That doesn't seem possible with the above example.

I could make a subdir server, put server.go in there, and change it to package server. The problem here is that I can't seem to shared common.go between the main and the server package. I understand why, it doesn't seem like a good idea either.

So I am missing something simple here and making this more complicated?

Thanks!

答案1

得分: 2

我认为你希望在项目中使用一些常用的方法是合理的假设。就像你将服务器分开一样,你应该将包含常用方法的包也分开。虽然最好按照一些逻辑方式进行思考和组织,而不是将包命名为toolsmisc等等。

我倾向于将事物分成包,这样它们可以在其他地方使用,而主要的包只需进行标志解析和调用库方法,例如server.Run()。其他人喜欢将所有东西都放在主项目中,如果你认为人们会将你的项目用作命令行工具而不是包,这样做也许是可以的。

我会考虑以下结构:

deamon/
    main.go
    server/server.go
    somelib/somelib.go -- 从main和server中引用

如果你希望你的项目主要用作包,但仍然包含一些命令行工具,你可以考虑以下结构:

deamon/
   deamon.go -- 包deamon
   deamond/
       main.go -- 你可以像其他人一样引用顶层包

我们需要记住,在Go中,你使用绝对路径来引用包,所以你可以将你的“公共”内容放在项目的任何位置,或者如果你决定它本身有用,可以发布一个独立的项目。

英文:

I think it's fair assumption you'd like to use some common methods across your projects. The same way you separate the server, you should then separate the package with the common methods. Although it's probably better to think and organise it in some logical way, rather than calling the package tools, misc etc.

I tend to split things into packages, so they can be used in other places, while the main package would be simply flag parsing and calling the library methods, for example server.Run(). Other people like to put everything into the main project, which might be all right if you think people would use your project as a command line tool, rather than a package.

I would consider:

deamon/
    main.go
    server/server.go
    somelib/somelib.go -- to be included from main and server

If you would like your project to be used mainly as a package, but still include some command line utility, you might consider:

deamon/
   deamon.go -- package deamon
   deamond/
       main.go -- you may include the top level package as anyone else

We need to remember that in Go you include your packages with an absolute path, so you can keep your "common" stuff anywhere in the project, or if you decide is useful by itself, just release a separate, standalone project.

huangapple
  • 本文由 发表于 2015年4月22日 01:05:42
  • 转载请务必保留本文链接:https://go.coder-hub.com/29778778.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定