命名类的最佳方法是什么？

Question

命名类的最佳方法是什么？

提出好的,准确的课程名称是众所周知的困难.如果做得好,它会使代码更加自我记录,并提供一个词汇表来推断更高抽象级别的代码.

实现特定设计模式的类可以根据众所周知的模式名称(例如FooFactory,FooFacade)给出一个名称,直接模拟域概念的类可以从问题域中获取它们的名称,但是其他类呢？当我缺乏灵感,并且想避免使用泛型类名(如FooHandler,FooProcessor,FooUtils和FooManager)时,有什么类似于程序员的词库吗？

Answer 1

Mar*_*iar 57

我将引用Kent Beck的Implementation Patterns的一些段落:

简单的超类名称

"[...]名称应该简短而有力.然而,为了使名称精确有时似乎需要几个词.摆脱这种困境的一种方法是选择一个强有力的计算隐喻.用一个比喻记住,甚至单词带来了丰富的关联,连接和含义网络.例如,在HotDraw绘图框架中,我在绘图中对象的第一个名字是 DrawingObject.Ward Cunningham出现了排版隐喻:绘图就像一个打印的布局页面.页面上的图形项目是数字,因此该类成为图形.在隐喻的上下文中,图形同时比DrawingObject更短,更丰富,更精确."

合格的子类名称

"子类的名称有两个作业.它们需要传达它们是什么类以及它们是如何不同的.[...]与层次结构根源的名称不同,子类名称在对话中几乎不常使用,所以他们可以以简洁为代价表达.[...]

将作为层次结构根的子类赋予其自己的简单名称.例如,HotDraw有一个Handle类,它在选择图形时显示图形编辑操作.简单地说, 尽管扩展了图,它仍然是Handle.有一整套手柄,它们最适合像StretchyHandle和TransparencyHandle这样的名字 .因为Handle是它自己的层次结构的根,所以它比一个合格的子类名更值得一个简单的超类名.

子类命名的另一个缺点是多级层次结构.[...]而不是盲目地将修饰符添加到直接超类中,从读者的角度考虑名称.他需要什么课才能知道这堂课是什么样的？使用该超类作为子类名称的基础."

接口

两种类型的命名接口取决于您如何考虑接口.作为没有实现的类的接口应该被命名为它们是类(简单超类名称,合格子类名称).这种命名方式的一个问题是,在命名类之前,好的名称已经用完了.名为File的接口需要一个名为ActualFile,ConcreteFile或(yuck!)FileImpl的实现类 (后缀和缩写).通常,无论是将抽象对象实现为接口还是超类都不太重要,无论是处理具体对象还是抽象对象进行通信都很重要.延迟界面和超类之间的区别很好地支持这种命名方式,如果有必要,您可以在以后随意改变主意.

有时,命名具体类对于通信而言比隐藏接口的使用更为重要.在这种情况下,前缀接口名称为"I".如果接口名为IFile,则该类可以简单地称为File.

有关更详细的讨论,请购买本书!这很值得!:)

“有时，简单地命名具体类对于通信比隐藏接口的使用更重要。在这种情况下，在接口名称前加上“I”前缀。如果接口称为 IFile，则该类可以简单地称为 File。” 这很有趣，因为在 Robert C. Martin 的《Clean Code》一书中，我发现我们宁愿将实现命名为 FileImpl，而不是将接口命名为 IFile，因为我们不希望客户端知道我们正在为他们提供服务界面。书中引用了您所引用的书中的内容 :) (2认同)

Answer 2

Rob*_*per 38

总是去MyClassA,MyClassB - 它允许一个不错的alpha排序..

我在开玩笑!

这是一个很好的问题,也是我不久前经历过的事情.我在工作中重新组织我的代码库,并且在哪里放置什么以及它叫什么都有问题.

在真正的问题？

我上课的时间太多了.如果你试图遵循单一责任原则,它将使所有内容更好地结合在一起.而不是一个单片PrintHandler类,你可以将它分解为PageHandler,PageFormatter(等等),然后有一个主打印机类,将它们汇集在一起.

在我的组织中,我花了很多时间,但是我最终将很多重复的代码分类,让我的代码库更加合理,并且在考虑在类中抛出额外的方法之前进行思考时学到了很多东西:D

但是,我不建议将类似名称的内容放入类名中.类接口应该显而易见(比如隐藏单例的构造函数).如果类正在服务于通用目的,则通用名称没有任何问题.

祝好运!

我宁愿在名字中加上模式的名称.为什么？因为如果我必须查看实现细节(比如私有构造函数)才能发现它是一个单例,这会让我放慢作为读者的速度,并且根据我的技能水平,我可能不会发现它实际上是一个类的部分一般模式.单例和私有构造函数是一个值得怀疑的例子,但对于更复杂的模式(访问者,适配器等),它变得非常复杂.如果模式发生变化,那么这些类将不再存在...... (2认同)