为类想出好的、精确的名称是出了名的困难。如果做得好,它可以使代码更加自我记录,并提供用于在更高抽象级别推理代码的词汇表。

实现特定设计模式的类可能会根据众所周知的模式名称来命名(例如FooFactory、FooFacade)以及直接对域概念建模的类可以从问题域中获取名称,但是其他类呢?当我缺乏灵感并且想要避免使用通用类名(如 FooHandler、FooProcessor、FooUtils 和 FooManager)时,有没有类似程序员同义词库的东西可以参考?

有帮助吗?

解决方案

我将引用一些段落 实施模式 作者:肯特·贝克:

简单的超类名称

“[...] 名字应该简短而有力。但是,要使名称确切,有时似乎需要几个单词。摆脱这一难题的方法是为计算挑选一个强大的比喻。考虑到一个隐喻,即使是单词也带来了丰富的关联,联系和含义的网络。例如,在热水绘图框架中,我在图形中的对象的名字是 绘图对象. 。沃德·坎宁安(Ward Cunningham)带有版式隐喻:图纸就像打印的铺设页面。页面上的图形项目是数字,所以课程变成了 数字。在比喻的语境中, 数字比较短,更丰富,更精确 绘图对象."

合格的子类名称

“子类的名称有两个作用。他们需要传达自己是什么样的班级以及如何与众不同。...]与层次结构根源的名称不同,在对话中几乎没有经常使用子类名称,因此它们可以以简洁的代价表达出来。[...]

给出作为层次结构根源的子类别的简单名称。例如, 热抽 有课 处理 当选择一个图时,哪个提出了数字编辑操作。简单地说,它被称为 处理尽管延长 数字. 。有一个全家的手柄,他们最适当的名字 弹力手柄透明句柄。因为 处理 它是其自身层次结构的根源,它值得一个简单的超类名称,而不是合格的子类名称。

子类命名的另一个皱纹是多层层次结构。...]从读者的角度来看,而不是盲目地将修饰符授予即时超级类别。他需要知道什么课是什么?使用该超类作为子类名称的基础。”

界面

两种风格的接口命名取决于您如何看待接口。接口作为没有实施的类的类别,应像类别一样命名(简单的超类名称, 合格的子类名称)。这种命名风格的一个问题是,在参加命名课程之前,好名字已经用完了。一个称为的接口 文件 需要一个名为类似的实现类 实际文件, 具体文件, ,或者(哎呀!) 文件实现 (后缀和缩写)。通常,传达一个人是否正在处理具体对象还是抽象对象很重要,是否将抽象对象作为接口或超类实现不太重要。这种命名风格很好地支持了界面和超类之间的区别,因此,如果有必要,您以后可以自由地改变主意。

有时,命名混凝土类对于通信而言比隐藏界面的使用更重要。在这种情况下,请在接口名称前加上“I”前缀。如果接口称为 文件, ,该类可以简单地称为 文件.

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

其他提示

始终选择 MyClassA、MyClassB - 它允许进行良好的 alpha 排序..

我在开玩笑!

这是一个很好的问题,也是我不久前经历过的事情。我在工作中正在重组我的代码库,并且遇到了在哪里放置什么以及如何称呼它的问题。

真实的 问题?

我的课做得太多了。如果您尝试遵守 单一责任原则 它会让一切都变得更好..而不是一个整体 打印处理程序 类,你可以将其分解为 页面处理程序 , 页面格式化程序 (等等)然后有一个主人 打印机 将所有内容结合在一起的类。

在我的重组中,我花了一些时间,但最终我删除了很多重复的代码,让我的代码库更加逻辑化,并且在在类中抛出额外方法之前进行思考时学到了很多东西:D

我会 不是 但是建议将模式名称之类的内容放入类名称中。类接口应该使这一点显而易见(就像隐藏单例的构造函数一样)。如果类服务于通用目的,则通用名称没有任何问题。

祝你好运!

乔什·布洛赫 (Josh Bloch) 的精彩演讲 良好的API设计 有一些好的建议:

  • 班级应该做一件事,并且把它做好。
  • 如果一个类很难命名或解释,那么它可能没有遵循上一个要点中的建议。
  • 类名应该立即传达该类是什么。
  • 好的名字带来好的设计。

如果您的问题是如何命名公开的内部类,也许您应该将它们合并到一个更大的类中。

如果您的问题是命名一个执行许多不同操作的类,您应该考虑将其分成多个类。

如果这对公共 API 来说是个好建议,那么它对任何其他类都不会造成伤害。

如果你不知道名字,有时只需给出它 任何 半明智的名称并承诺稍后修改它是一个很好的策略。

不要陷入命名瘫痪。是的,名字非常重要,但还没有重要到需要浪费大量时间的程度。如果您无法在 10 分钟内想出一个好名字,请继续。

如果我没有想到一个好名字,我可能会质疑是否存在更深层次的问题——这个类是否有一个好的目的?如果是的话,命名它​​应该非常简单。

如果你的“FooProcessor”确实处理 foos,那么不要仅仅因为你已经有了 BarProcessor、BazProcessor 等就不愿意给它起这个名字。当有疑问时,显而易见的是最好的。必须阅读您的代码的其他开发人员可能不会使用与您相同的同义词库。

也就是说,对于这个特定的例子来说,更多的特异性不会有什么坏处。“过程”是一个非常广泛的词。例如,它真的是一个“FooUpdateProcessor”(可能会变成“FooUpdater”)吗?您不必对命名过于“有创意”,但是如果您编写了代码,您可能非常清楚它做什么和不做什么。

最后,请记住,裸露的类名并不是您和代码读者必须继续进行的全部内容 - 通常还有名称空间在起作用。这些通常可以为读者提供足够的背景信息,以清楚地了解您的类的真正用途,即使它的名称相当通用。

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top