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

Question

官方 Go Code Review Comments 文档中的Interfaces规则说包应该返回具体类型而不是接口。这样做的动机是：...可以将新方法添加到实现中，而无需进行大量重构。我接受这可能是一件好事。但是，如果我正在编写的类型具有依赖性，没有它就无法达到目的怎么办？如果我导出具体类型，开发人员将能够在没有该依赖性的情况下实例化实例。为了针对缺失的依赖项进行防御性编码，我必须在每个方法实现中检查它，如果不存在则返回错误。如果开发人员在我的文档中遗漏了任何不要这样做的提示，她或他将在运行时之前不会了解问题。另一方面，如果我用客户端需要的方法声明并返回一个接口，我可以取消导出具体类型并强制使用接受依赖项作为参数并返回接口和错误的工厂方法。这似乎是确保正确使用包的更好方法。通过这样的思考，我是否以某种方式没有正确地进入 go 精神？语言的道德规范是否可以通过不完美的封装来为开发人员提供更大的灵活性？

Answer 1

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

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

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

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