The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
经理。控制器。助手。处理器。作者。读者。转换器。验证器。路由器。调度程序。观察者。监听器。排序器。编码器。解码器。这是耻辱之殿的类名。你在你的代码中见过它们吗？在你使用的开源库中见过它们吗？在模式书中见过它们吗？它们都是错误的。它们有什么共同之处？它们都以”-er”结尾。那有什么问题？它们不是类，它们实例化的对象也不是对象。相反，它们是假装是类的过程的集合。
Peter Coad 曾经说过：质疑任何以”-er”结尾的类名。关于这个主题有一些很好的文章，包括 Carlo Pescio 的 Your Coding Conventions Are Hurting You，Travis Griggs 的 One of the Best Bits of Programming Advice I Ever Got，以及 Ben Hall 的 Naming Objects – Don’t Use ER in Your Object Names。反对这个”-er”后缀的主要论点是”当你需要一个管理者时，往往意味着被管理的只是一些普通的数据结构，而真正工作的是管理者这个聪明的过程。”
我完全同意，但我想再补充几句话。
我已经在《好对象的七个美德》中提到，一个好的对象名称不是一个工作标题，但我没有解释为什么我这么认为。除此之外，在《实用类与函数式编程无关》中，我试图解释声明性编程和命令式编程范式之间的区别。现在是将这两个方面结合在一起的时候了。
假设我是一个对象，你是我的客户。你给我一桶苹果，并要求我按大小排序它们。如果我生活在命令式编程的世界中，你会立即得到排序好的苹果，我们将永远不会再互动。我会像你要求的那样完成工作，甚至不会思考*你为什么需要它们排序。我将成为一个不关心你真正意图的排序器：
正如你在这里看到的，真正的意图是在桶里找到最大的苹果。
这不是你期望的一个能帮助你处理一桶苹果的好商业伙伴。
相反，如果我生活在声明式编程的世界中，我会告诉你：“把它们视为已排序；接下来你想要做什么？”然后，你会告诉我你现在需要最大的苹果。我会说：“没问题；给你。”为了返回最大的苹果，我不会对它们进行排序。我只会逐个遍历它们并选择最大的。这个操作比先排序再选择列表中的第一个要快得多。
换句话说，我会默默地不按照你的指示去做，而是用我的方式经营我的生意。我会成为比那个命令式排序者更聪明的合作伙伴。我会变成一个行为像已排序苹果列表的真实对象，而不是一个进行排序的过程。
See the difference?
请特别注意sorter和sorted这两个名称之间的区别。
让我们回到类名。当你给类名加上”-er”后缀时，你立即将它变成了一个无知的命令式执行者，只能按照你的意愿去执行任务。你不允许它思考和创新。你期望它完全按照你的要求来做事——排序、管理、控制、打印、写入、合并、连接等等。
一个对象是一个活生生的有机体，它不想被告诉该做什么。它想成为其他对象的平等伙伴，根据它的契约（在Java和C#中称为接口，Swift中称为协议）来展示行为。
从哲学上讲，”-er”后缀是对可怜的对象的一种不尊重的象征。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-22 at 10:35
