不要创建以er结尾的对象

Manager、Controller、Helper、Handler、Writer、Reader、Converter、Validator、 Router、Dispatcher、Observer、Listener、Sorter、Encoder、Decoder，这是类名的黑名单。在你的代码、用过的开源库和教材里有见到过它们吗？它们全是错的。它们有什么共同点？它们全是以 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 后缀是因为：当你需要一个管理者的时候，通常标志着被管理的只是一些简单的数据结构，而管理者是做这些工作的智能程序。

我完全同意，但要对此再补充几句。

我在 Seven Virtues of a Good Object 已经提到过一个好的对象名不是一项工作的标题，但是我没有解释我为什么这么认为。此外，在 Utility Classes Have Nothing to Do With Functional Programming 中，我试图去解释声明式编程和命令式编程的区别。现在是时候把这两块内容放一起了。

比方说我是一个对象，你是我的客户。你给我一桶苹果让我把它们按大小排序。如果我生活在命令式编程的世界里，你将立刻得到排序过的它们，而且我们再也不会产生交互。我只是按照请求去做我的工作，甚至不会去考虑为什么你需要将他们排序。我只是一个完全不关心你真正意图的排序机而已：

List<Apple> sorted = new Sorter().sort(apples);Apple biggest = sorted.get(0);

正如你看到的，真正的目的是找出桶里最大的苹果。

这不是你希望从一个能帮助你从事一桶苹果工作的好的业务伙伴那儿得到的。

相反，如果我生活在声明式编程的世界里，我会告诉你：“想象它们是已经排过序的，接下来你想做什么”。反过来，你会告诉我你现在需要找出最大的苹果。我会说：“没问题，就是这个”。为了返回最大的一个，我不用它们都排序。我只需要一个一个的遍历就能选出最大的。这个操作比先排序然后选择列表中的第一个快了很多。

换句话说，我私底下不会按照你的指示去做，但是我会尝试用我的方式去做我的业务。比起命令式排序机我将是你更聪明的合作伙伴。而且我将成为一个行为像已排序过的苹果列表的真正意义上的对象而不是排序的程序：

List<Apple> sorted = new Sorted(apples);Apple biggest = sorted.get(0);

看出差异了吗？

特别要注意一下 sorter 和 sorted 的名字。

让我们回到类名的问题上来。当你把你的类名加上 er 后缀时，你立刻把它变成了一个完成你意愿的愚蠢的命令执行者。你不允许思考和发挥。你希望的是你想怎样它就怎样：排序、管理、控制、打印、写、结合、连接等等。

对象是一个不想被告诉要做什么的生命体。它想与其它对象之间是平等的伙伴关系，根据它在 Java 和 C# 里的合同（又名接口）或者在 Swift 里的协议暴露行为。
从哲学上讲，er 后缀是一种不尊重贫困对象的标志。

---

本文是一篇译文，点击《Don’t Create Objects That End With -ER》查看原文，如有翻译不当的地方欢迎指出。如需转载，请标明原文和译文的出处，谢谢。

微信扫一扫 查看更多内容