处理GO中的全局状态的方法

在处理大型项目时，全局变量的使用可能会带来封装问题。本文探讨了在 Go 中处理全局状态的替代方法，建议将配置变量封装在单独的包中并通过方法或构造函数参数传递。这种方法可以提高可测试性和可维护性，同时仍然保持配置数据的可访问性。

我最近加入了一个项目，其中有一个外部配置样式服务 - 基本上是一个使用 jsonrpc 调用的 KV 存储。

不要问它为什么在那里..

我需要查询此配置服务以获得代码库内部使用的白名单。

但是，如果不使用全局变量，我就无法找到解决方案。例如，我调用一个函数来从包 A 中获取配置，但必须导出 var 才能在其他包中使用它。我最初的解决方案是使用 gocache 在包内设置缓存并导出缓存访问器以具有某种类型限制。然而，这增加了复杂性，并且看起来比仅仅将 val 存储在导出的 var 中要复杂得多。

我已经看到标准库中使用了全局变量，但很困惑，因为这违反了封装法则？

非常感谢任何有关如何解决此类问题的建议。

解决方案

如果您的项目很小或者预计不会有太大变化，那么全局 配置可能没问题。不过，我会将配置变量放在它自己的包中。另一方面，如果该项目预计增长超过 随着时间的推移，将事物封装起来是有意义的。

您能否将配置作为参数从包 a 传递到任何其他包 需要以方法或构造函数参数的形式？我认为传递的东西 around 使得对配置的依赖变得明显，并且也允许更容易 在测试中进行模拟。

就我个人而言，我会像这样构建项目（如果我从头开始工作 - 可能不是你所拥有的奢侈品）：

project root
|
|- config/
|  |- Config (interface) -> knows how to fetch config form JSON-RPC and caches it if necessary
|  |  |- GetSomething1()
|  |  |- GetSomething2()
|  |  |- Get(key string) -> If you have arbitrary keys
|  |
|  |- NewJsonRpcConfig(settings) -> returns something that implements the Config interface
|
|- main.go -> calls config.NewConfig()
   |
   |- Passes the resulting Config interface as a parameter to anything that needs it.
      Packages don't directly interact with a global variable.

所有配置内容都在 config 包中。它可以与 json-rpc 对话 服务器，也许缓存结果并返回配置。 main 包 创建配置获取器的实例并将其传递给所有实例 需要使用配置。

到这里，我们也就讲完了《处理GO中的全局状态的方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！