命名子类的最佳实践
我经常遇到这样的情况：我有一个由接口或类表示的概念，然后我有一系列扩展它的子类/子接口。
例如： 通用的“DoiGraphNode” 代表资源的“DoiGraphNode” 代表 Java 资源的“DoiGraphNode” 具有关联路径的“DoiGraphNode”等。
我可以想到三种命名约定，并且希望就如何选择提供评论。
- 选项 1：始终以概念名称开头。
因此：DoiGraphNode、DoiGraphNodeResource、DoiGraphNodeJavaResource、DoiGraphNodeWithPath 等。
优点：我正在处理的内容非常清楚，很容易看到我拥有的所有选项
。缺点：不是很自然？ 一切看起来都一样吗？
- 选项 2：将特殊内容放在开头。
因此： DoiGraphNode、ResourceDoiGraphNode、JavaResourceDoiGraphNode、PathBaseDoiGraphNode 等。
优点：当我在代码中看到它时，它非常清楚。缺点
：找到它可能很困难，特别是如果我不记得名字的话，缺乏视觉一致性
- 选项3：放置特殊的内容并删除一些多余的文本
因此：DoiGraphNode，ResourceNode，JavaResourceNode，GraphNodeWithPath
优点：不需要太多的写入和读取 缺点：看起来像 cr*p，非常不一致，可能与其他名称冲突
I am often in a situation where I have a concept represented by an interface or class, and then I have a series of subclasses/subinterfaces which extend it.
For example:
A generic "DoiGraphNode"
A "DoiGraphNode" representing a resource
A "DoiGraphNode" representing a Java resource
A "DoiGraphNode" with an associated path, etc., etc.
I can think of three naming conventions, and would appreciate comments on how to choose.
- Option 1: Always start with the name of the concept.
Thus: DoiGraphNode, DoiGraphNodeResource, DoiGraphNodeJavaResource, DoiGraphNodeWithPath, etc.
Pro: It is very clear what I am dealing with, it is easy to see all the options I have
Con: Not very natural? Everything looks the same?
- Option 2: Put the special stuff in the beginning.
Thus: DoiGraphNode, ResourceDoiGraphNode, JavaResourceDoiGraphNode, PathBaseDoiGraphNode, etc.
Pro: It is very clear when I see it in the code
Con: Finding it could be difficult, especially if I don't remember the name, lack of visual consistency
- Option 3: Put the special stuff and remove some of the redundant text
Thus: DoiGraphNode, ResourceNode, JavaResourceNode, GraphNodeWithPath
Pro: Not that much to write and read
Con: Looks like cr*p, very inconsistent, may conflict with other names
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
根据它们的本质来命名它们。
如果命名它们很困难或含糊不清，这通常表明该类做得太多（单一职责原则）。
为了避免命名冲突，请适当选择名称空间。
就我个人而言，我会使用 3
Name them for what they are.
If naming them is hard or ambiguous, it's often a sign that the Class is doing too much (Single Responsibility Principle).
To avoid naming conflicts, choose your namespaces appropriately.
Personnally, I'd use 3
你喜欢用什么就用什么，这是一个主观的事情。 重要的是要明确每个类代表什么，并且名称应该使继承关系有意义。 不过，我真的认为在名称中编码关系并不是那么重要； 这就是文档的用途（如果您的名称适合对象，人们应该能够很好地猜测什么继承了什么）。
就其价值而言，我通常使用选项 3，根据我查看其他人代码的经验，选项 2 可能比选项 1 更普遍。
Use whatever you like, it's a subjective thing. The important thing is to make clear what each class represents, and the names should be such that the inheritance relationships make sense. I don't really think it's all that important to encode the relationships in the names, though; that's what documentation is for (and if your names are appropriate for the objects, people should be able to make good guesses as to what inherits from what).
For what it's worth, I usually use option 3, and from my experience looking at other people's code option 2 is probably more prevalent than option 1.
我通常命名类似于选项 1，特别是当类以多态方式使用时。
我的理由是，最重要的信息应该首先列出。
（即子类基本上就是祖先的事实，
（通常）“添加”扩展名）。
我喜欢这个选项还因为在对类名列表进行排序时，
相关的类将一起列出。
即我通常将翻译单元（文件名）命名为
类名那么相关的类文件自然会被列在一起。
同样，这对于增量搜索很有用。
尽管我在编程生涯的早期倾向于使用选项 2，但现在我避免使用它，因为正如您所说，它“不一致”并且看起来不太正交。
当子类提供大量扩展或规范，或者名称相当长时，我经常使用选项 3。
例如，我的文件系统名称类是从 String 派生的
但它们极大地扩展了 String 类并且有显着不同
用途/含义：
从 String 派生的 Directory_entry_name 添加了广泛的功能。
从 Directory_entry_name 派生的 File_name 具有相当专门的功能。
从 Directory_entry_name 派生的 Directory_name 也具有相当专门的功能。
另外，与选项 1 一起，我通常对接口类使用非限定名称。
例如，我可能有一个类接口链：
我更喜欢接口和抽象基类自动出现在排序列表中的第一个。
I usually name similar to option 1, especially when the classes will be used polymophically.
My reasoning is that the most important bit of information is listed first.
(I.e. the fact that the subclass is basically what the ancestor is,
with (usually) extensions 'added').
I like this option also because when sorting lists of class names,
the related classes will be listed together.
I.e. I usually name the translation unit (file name) the same as
the class name so related class files will naturally be listed together.
Similarly this is useful with incremental search.
Although I tended to use option 2 earlier in my programming career, I avoid it now because as you say it is 'inconsistant' and do not seem very orthogonal.
I often use option 3 when the subclass provides substantial extension or specification, or if the names would be rather long.
For example, my file system name classes are derived from String
but they greatly extend the String class and have a significantly different
use/meaning:
Directory_entry_name derived from String adds extensive functionality.
File_name derived from Directory_entry_name has rather specialized functions.
Directory_name derived from Directory_entry_name also has rather specialized functions.
Also along with option 1, I usually use an unqualified name for an interface class.
For example I might have a class interence chain:
I rather like that the interface and the abstract base class automatically appear first in the sorted list.
您可以在编码标准文档中找到一些指导，例如，这里有 C# 的 IDesign 文档< /a>.
就我个人而言，我更喜欢选项 2。这通常是 .NET Framework 命名其对象的方式。 例如查看属性类。 它们都以属性 (TestMethodAttribute) 结尾。 EventHandler 也是如此：OnClickEventHandler 是处理 Click 事件的事件处理程序的推荐名称。
我通常在设计自己的代码和界面时尝试遵循这一点。 因此，IUnitWriter 生成 StringUnitWriter 和 DataTableUnitWriter。 这样我总是知道他们的基类是什么，并且读起来更自然。 自记录代码是所有敏捷开发人员的最终目标，所以它似乎对我来说很有效！
You could find some guidance in a coding standards document, for example there is the IDesign document for C# here.
Personally, I prefer option 2. This is generally the way the .NET Framework names its objects. For instance look at attribute classes. They all end in Attribute (TestMethodAttribute). The same goes for EventHandlers: OnClickEventHandler is a recommended name for an event handler that handles the Click event.
I usually try to follow this in designing my own code and interfaces. Thus an IUnitWriter produces a StringUnitWriter and a DataTableUnitWriter. This way I always know what their base class is and it reads more naturally. Self-documenting code is the end-goal for all agile developers so it seems to work well for me!
选项三更符合继承概念。 由于您正在专门化接口或类，因此名称应该表明它不再使用基本实现（如果存在）。
有多种工具可以查看类继承自什么，因此指示类的实际功能的简洁名称比尝试将太多类型信息打包到名称中更有效。
Option three more logically follows from the concept of inheritance. Since you're specializing the interface or class, the name should show that it's no longer using the base implementation (if one exists).
There are a multitude of tools to see what a class inherits from, so a concise name indicating the real function of the class will go farther than trying to pack too much type information into the name.