如何在遵守接口上的 golang CodeReviewComments 规则的同时强制执行正确的构造？

Question

官方 Go Code Review Comments 文档中的 Interfaces 规则说包应该返回具体类型而不是接口。这样做的动机是：

...无需大量重构即可将新方法添加到实现中。

我接受这可能是件好事。

但是，如果我正在编写的类型具有依赖项，没有它就无法达到目的怎么办？如果我导出具体类型，开发人员将能够实例化没有这种依赖关系的实例。为了对缺失的依赖进行防御性编码，我必须在每个方法实现中检查它，如果不存在则返回错误。如果开发人员在我的文档中错过了不要这样做的任何提示，她或他将在运行时才知道问题。

另一方面，如果我声明并返回带有客户端所需方法的接口，我可以取消导出具体类型并强制使用工厂方法，该方法接受依赖项作为参数并返回接口和错误.这似乎是确保正确使用包的更好方法。

我是不是因为这样想而没有正确地进入围棋精神？语言的伦理是否允许有一个不太完美的封装来为开发人员提供更多的灵活性？

Answer 1

您可能希望开发人员阅读您提供的文档，并且您可以按照您设置的规则依赖他们。是的，懒惰的开发者时不时会撞到头，但开发的过程并非不用学习。一切都不能明确或强制执行，没关系。

如果你有一个导出的结构类型Example 并且你提供了一个构造函数NewExample()，这清楚地表明NewExample() 应该用于构造Example 的值。任何试图手动构建Example 的人都应该知道必须设置哪些字段才能使其“可操作”。目标始终是使零值完全起作用，但如果无法实现，构造函数是惯用的方法。

这并不罕见，标准库中有无数示例，例如http.Request、json.Encoder、json.Decoder、io.SectionReader、template.Template。

您必须确保的是，如果您的包返回结构的值，则必须（应该）正确初始化它们。而且，如果希望其他人传递由他们创建的结构的值，则必须为他们提供一种简单的方法来创建结构的有效值（构造函数）。其他开发人员自己创建的自定义结构值是否“有效”，您不必担心。