命名类的最佳方法是什么? [英] What's the best approach to naming classes?

问题描述

想出一个好的，精确的类名是非常困难的.做得对，它使代码更具自记录性，并提供了用于在更高抽象级别上进行代码推理的词汇表.

Coming up with good, precise names for classes is notoriously difficult. Done right, it makes code more self-documenting and provides a vocabulary for reasoning about code at a higher level of abstraction.

可以基于众所周知的模式名称(例如FooFactory，FooFacade)为实现特定设计模式的类命名，而直接为领域概念建模的类可以从问题域中获取其名称，而其他类呢? ?

Classes which implement a particular design pattern might be given a name based on the well known pattern name (e.g. FooFactory, FooFacade), and classes which directly model domain concepts can take their names from the problem domain, but what about other classes? Is there anything like a programmer's thesaurus that I can turn to when I'm lacking inspiration, and want to avoid using generic class names (like FooHandler, FooProcessor, FooUtils, and FooManager)?

推荐答案

我将引用:

I'll cite some passages from Implementation Patterns by Kent Beck:

"[...]名称应简短而有力. 但是，为了使名称准确 有时似乎需要几个 字.摆脱这种困境的方法是 为...选择一个强有力的隐喻 计算.想到一个比喻， 即使是一个字也带来了 丰富的联系，联系网络， 和含义.例如，在 HotDraw绘图框架，我的第一个 工程图中对象的名称为 DrawingObject .病房坎宁安来了 连同版式隐喻: 图纸就像印刷的布局 页.页面上的图形项是 数字，因此该班级成为了数字. 在隐喻的上下文中，图 同时更短，更丰富，并且 比 DrawingObject 更精确."

"[...] The names should be short and punchy. However, to make the names precise sometimes seems to require several words. A way out of this dilemma is picking a strong metaphor for the computation. With a metaphor in mind, even single words bring with them a rich web of associations, connections, and implications. For example, in the HotDraw drawing framework, my first name for an object in a drawing was DrawingObject. Ward Cunningham came along with the typography metaphor: a drawing is like a printed, laid-out page. Graphical items on a page are figures, so the class became Figure. In the context of the metaphor, Figure is simultaneously shorter, richer, and more precise than DrawingObject."

合格的子类名称

子类的名称有两个工作. 他们需要交流什么课 他们就像，他们如何 不同的. [...]与处的名字不同 层次结构的根，子类 名称的使用频率几乎没有 对话，所以他们可以 以存在为代价表达 简洁的. [...]

"The names of subclasses have two jobs. They need to communicate what class they are like and how they are different. [...] Unlike the names at the roots of hierarchies, subclass names aren’t used nearly as often in conversation, so they can be expressive at the cost of being concise. [...]

提供子类作为 层次结构的根源本身很简单 名称.例如， HotDraw 具有一个 类句柄，其中显示了图- 人物时的编辑操作 已选择.简称为 Handle (句柄) 尽管扩展了图形.有 整个家族的把手，他们 最合适的名字像 StretchyHandle 和 TransparencyHandle . 因为 Handle 是其自身的根 等级制度，它值得一个简单的 超类名不止一个合格 子类名称.

Give subclasses that serve as the roots of hierarchies their own simple names. For example, HotDraw has a class Handle which presents figure- editing operations when a figure is selected. It is called, simply, Handle in spite of extending Figure. There is a whole family of handles and they most appropriately have names like StretchyHandle and TransparencyHandle. Because Handle is the root of its own hierarchy, it deserves a simple superclass name more than a qualified subclass name.

另一个皱纹 子类命名是多级的 层次结构. [...]而不是盲目 将修饰符放在立即数之前 超类，从中考虑名字 读者的观点.什么级别 他是否需要知道这堂课是 喜欢?使用该超类作为基础 子类名称."

Another wrinkle in subclass naming is multiple-level hierarchies. [...] Rather than blindly prepend the modifiers to the immediate superclass, think about the name from the reader’s perspective. What class does he need to know this class is like? Use that superclass as the basis for the subclass name."

界面

两种命名界面的样式取决于您对界面的看法. 作为没有实现的类的接口应命名为类 (简单超类名称，合格子类名称).这种风格的一个问题 命名是在使用命名类之前，好名字就被用完了.一个 名为 File 的接口需要一个实现类，例如 ActualFile ， ConcreteFile 或(糟糕！) FileImpl (后缀和 缩写).一般而言，沟通一个人是在处理具体问题还是在处理问题 无论抽象对象是否实现为抽象对象，抽象对象都很重要 接口或超类次要的.延迟两者之间的区别 这种命名方式很好地支持了接口和超类，让您 如有必要，可以稍后再改变主意.

Two styles of naming interfaces depend on how you are thinking of the interfaces. Interfaces as classes without implementations should be named as if they were classes (Simple Superclass Name, Qualified Subclass Name). One problem with this style of naming is that the good names are used up before you get to naming classes. An interface called File needs an implementation class called something like ActualFile, ConcreteFile, or (yuck!) FileImpl (both a suffix and an abbreviation). In general, communicating whether one is dealing with a concrete or abstract object is important, whether the abstract object is implemented as an interface or a superclass is less important. Deferring the distinction between interfaces and superclasses is well >supported by this style of naming, leaving you free to change your mind later if that >becomes necessary.

有时候，命名具体的类对沟通比对沟通更重要 隐藏接口的使用.在这种情况下，请使用"I"作为接口名称的前缀.如果 界面称为 IFile ，该类可以简称为 File .

Sometimes, naming concrete classes simply is more important to communication than hiding the use of interfaces. In this case, prefix interface names with "I". If the interface is called IFile, the class can be simply called File.

要进行更详细的讨论，请购买本书！这很值得！ :)

For more detailed discussion, buy the book! It's worth it! :)

这篇关于命名类的最佳方法是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！