什么是命名类的最好方法？
为class级准备好名字是非常困难的。 做对了，它使代码更加自我logging，并提供了一个词汇，用于在更高的抽象层次上对代码进行推理。
实现特定devise模式的类可能会根据众所周知的模式名称（例如FooFactory，FooFacade）给出一个名称，而直接为域概念build模的类可以从问题域中取名，但其他类又如何呢？ 有没有什么东西像程序员的词库，当我缺乏灵感时，我可以转向，并且要避免使用generics类名（如FooHandler，FooProcessor，FooUtils和FooManager）？
我会引用Kent Beck 实施模式的一些话：
简单的超类名称
“[…]名字应该简短而有力，但为了使名字更加精确，有时似乎需要几个字。解决这个难题的一个办法是select一个强大的计算隐喻。一个单词带来了丰富的关联，连接和暗示networking，例如，在HotDraw绘图框架中，我在graphics中的名字是DrawingObject ，Ward Cunningham带着印刷术的隐喻出现了：绘图就像一个页面上的graphics项目是graphics，所以类就变成了graphics ，在隐喻的背景下， graphics比DrawingObject同时更短，更丰富，更精确。
合格的子类名称
“子类的名字有两个工作，他们需要交stream他们是什么类，他们是怎样不同的。[…]与层次结构根名称不同，子类名称在对话中几乎不常用，所以他们可以expression的代价是简洁。[…]
给作为层次结构根的子类提供自己的简单名称。 例如， HotDraw有一个类Handle ，它在select一个graphics时显示graphics编辑操作。 它被称为，简单地说，尽pipe延伸图 。 有一个完整的句柄系列，最合适的名称是StretchyHandle和TransparencyHandle 。 因为Handle是它自己的层次结构的根，所以它比一个合格的子类名称更值得一个简单的超类名称。
子类命名中的另一个折痕是多级层次结构。 […]而不是盲目地把修饰语加到直接的超类，从读者的angular度思考这个名字。 他需要什么课程来认识这个class级？ 使用该超类作为子类名称的基础。“
接口
两种风格的命名接口取决于你如何考虑接口。 接口作为没有实现的类应该被命名为它们是类（ 简单超类名 ， 合格子类名 ）。 这种命名方式的一个问题是，在命名类之前，好名字已经用完了。 一个名为File的接口需要一个类似ActualFile ， ConcreteFile或（ yuck ！） FileImpl （后缀和缩写）的实现类。 一般而言，传达一个人是否正在处理一个具体或抽象的对象是很重要的，不pipe抽象对象是作为一个接口还是一个超类来实现都不那么重要。 推迟界面和超类之间的区别是由这种命名方式所支持的，如果这种方式变得必要，以后可以自由地改变主意。
有时，命名具体类对于通信来说比隐藏接口更重要。 在这种情况下，前缀接口名称与“我”。 如果该接口被称为IFile ，则该类可以简单地称为File 。
如需更详细的讨论，请购买本书！ 这很值得！ 🙂
总是去MyClassA，MyClassB – 它允许一个不错的阿尔法sorting..
我在开玩笑！
这是一个很好的问题，也是我不久前经历的事情。 我正在重新组织我的代码库，并且遇到了什么问题，以及该怎么称呼它..
真正的问题？
我上课太多了。 如果你试图坚持单一责任原则，它会使所有的东西都聚集在一起更好..不是一个单一的PrintHandler类，你可以分解成PageHandler ， PageFormatter （等等），然后有一个主要的Printer类把它一起带来
在我的re-org中，花了我不less时间，但是我最终把很多重复的代码打包了出来，让我的代码库变得更加合乎逻辑，并且在抛出一个额外的方法之前先思考了很多：D
然而，我不会推荐将类似名称的东西放入类名中。 类接口应该明显（像隐藏单身的构造函数）。 通用名称没有问题，如果这个类是通用的。
祝你好运！
Josh Bloch关于优秀APIdevise的精彩演讲有几点build议：
- 课堂应该做一件事情，做得好。
- 如果一个class级很难说出或解释，那么它可能不会遵循上一个要点的build议。
- 类名应该立即传达类是什么。
- 好名字驱动好devise。
如果你的问题是公开的内部类的问题，也许你应该把它们合并成一个更大的类。
如果你的问题是命名一个正在做很多不同的东西的类，你应该考虑把它分成多个类。
如果这是一个公共API的好build议，那么它不能伤害任何其他类。
如果你被一个名字困住了，有时候只是给它一个半明智的名字，并承诺在以后修改这个名字是一个很好的策略。
不要命名瘫痪。 是的，名字是非常重要的，但他们不重要，浪费了大量的时间。 如果你在10分钟内想不出一个好名字，继续前进。
如果一个好名字没有想到，我可能会质疑是否有更深层次的问题 – 这个class级是否有一个好的目标？ 如果是这样，命名应该是非常简单的。
如果你的“FooProcessor”真的在处理foos，那么不要因为你已经有了一个BarProcessor，BazProcessor等等而不愿意给它这个名字。如果有疑问，显然是最好的。 必须阅读代码的其他开发人员可能不会使用与您相同的同义词库。
也就是说，对于这个特殊的例子来说，更具体的特征并不会受到伤害 “过程”是一个相当宽泛的词。 它真的是“FooUpdateProcessor”（可能成为“FooUpdater”），例如？ 你不需要对命名过于“富有创造性”，但是如果你编写了代码，你可能对它做了什么也不知道它做了什么。
最后，请记住，纯粹的类名不是你所有的，你的代码的读者必须继续 – 通常也有命名空间。 那些经常给读者足够的上下文来清楚地看到你的课程是否真正适用，即使它的名字是相当通用的。
