不要害怕使用 Types
不要害怕使用 Types
我发现，在我参与的代码库中，大家似乎不太愿意创建新的 types。早期我在 Java 项目中工作时就注意到了这一点，现在偶尔在 Go 项目中也能看到。函数体中有很多局部变量，函数接受大量的参数或者返回大量的返回值，以及对现有 types 进行扩展而不是创建新的 types。这是一种奇怪的现象。
我无法解释这是为什么。也许是害怕感觉自己正在篡改代码库的“宏伟设计”。这可能是因为我作为初级开发人员时就有这种感觉。害怕在 Java 中创建新的类，认为我正在为项目引入一个新的概念，而其他人必须在未来处理它。我可以添加所有我想要的动词，但我是谁，竟然敢引入一个新的名词？
当你仔细思考几秒钟后，这显然是一个荒谬的想法。如果你想出了一个概念或者一系列自然组合在一起的值，以至于你在一系列函数调用中将它们作为一系列参数传递，那么创建 type 可能会对你有好处。这就是 type 系统的用途：一种将相似的信息片段分组到一个易于使用的整体中的方法。
这对于应用程序模型来说完全有意义：这是你软件存在的理由所依赖的实体。但我发现为较小的信息片段创建 types 也很有用：例如，从 handlers 传递到服务层的请求。就在刚才，我正在编写一些处理创建 subscriptions 的代码。我需要将 office ID、customer ID、price ID、subscription 数量、税务设置和 subscription 元数据从 API handler 一直传递到 Stripe 客户端。这比 subscription 模型处理的要少，但仍然很难将这六个信息位分别通过 unmarshalling 逻辑、validation 逻辑，然后传递到服务器。
所以我做了什么？我创建了一个 “CreateSubscriptionRequest” struct，一个新的 type。是的，它不会是可重用的，但谁在乎呢？它使代码和我的生活更简单。老实说，我认为软件设计的整个“面向对象方法”确实搞砸了我们的想法。当时流行一种感觉，即 types 和 classes 是神圣的，创建新 type 是一种特权，只授予 leads、architects 以及任何有权访问 UML 图的人。每个 type 都应该是设计的人工制品，可能是因为定义新 type 会带来很多负担：它们必须位于单独的文件中，必须有七个不同的构造函数，并且字段必须通过使用 getters 和 setters 来进行中介。如果你需要与你正在处理的内容类似的东西，你不会像动物一样“复制粘贴”；你继承或组合现有的东西。鉴于所有这些，创建新的 types 感觉像是一个非常重要的决定，这可能是可以理解的。而你，一个卑微的初级开发人员，有什么资格做出这样的决定，创建一个 type 只是为了更容易处理来自你的 handler 的数据？
我认为 C 和 Go 的文化在这方面做得很好。需要为单个函数携带一些东西？创建一个新的 type。不要担心它只用于单个函数。不要担心它只包含你正在操作的模型的字段子集。1
现在很明显，有可能做得太过分，并开始拥有比必要的更多的 types。不要忘记，新的 type 会增加一些认知负担，因为维护你应用程序的人现在需要解包并引用你的 type，当他们需要处理它时。“CreateSubscriptionRequest” 使其计划这个 type 只处理创建 subscriptions 的代码区域，并且可能只在这些代码路径中有意义。
但听取一个不得不处理通过一系列函数调用传递和返回多个 strings、ints 和 bools 值的人的意见：一个简单的 struct 值更容易使用。所需要的只是有人鼓起勇气说“是的，那应该是一个 type。”
不要害怕成为那个人。
- 事实上，这可能比使用模型 type 并在函数文档中添加“此字段被忽略，该字段必须为零等等”更好。↩︎