命名类的最佳方法是什么?[关闭]

我会引用一些段落 Implementation Patterns 肯特·贝克:

简单超类名称

“[…]名字应该简短而有力。 但是,为了使名字准确 有时似乎需要几个 话。走出这种困境的方法是 为 计算。考虑到隐喻, 即使是一句话也会带来 丰富的联系网, 以及影响。例如,在 我的第一个热绘图框架 图形中对象的名称为 拖网目标 . 沃德·坎宁安来了 与排版隐喻一起:A 图纸就像是打印出来的 页。页面上的图形项是 数字,所以这个班变成了 图形 . 在隐喻的语境中, 图形 同时变得更短、更丰富和 比 拖网目标 ."

限定子类名称

“子类的名称有两个作业。 他们需要交流什么课程 它们的样子和样子 不同的。[…]不同于 层次结构的根,子类 在 对话,这样他们就可以 以牺牲 简洁的。[…]

给出作为 等级制度的根源 名字。例如, 热画 有一个 班 把手 哪个代表数字- 当图形为 挑选出来的。它被称为,简单地说, 把手 尽管延伸 图形 . 有 一整套把手 最合适的名字是 伸缩手柄 和 透明手柄 . 因为 把手 是它自己的根 等级制度,它应该有一个简单的 超类名称多于限定的 子类名称。

又一个皱纹 子类命名是多级别的 层次结构。不是盲目的 将修饰符前置到立即数 超类,想想它的名字 读者的观点。什么课 他需要知道这门课吗 喜欢吗?用那个超类作为基础 用于子类名称。“

界面

两种类型的命名接口取决于您对接口的看法。 作为没有实现的类的接口应命名为类 ( 简单超类名称 , 限定子类名称 )这种风格的一个问题 命名是指在命名类之前,好的名称已经用完。安 调用的接口 文件 需要一个名为 实际文件 , 混凝土文件 或者(哎呀!) 文件注入 (后缀和 缩写)。一般来说,沟通一个人是处理一个具体的还是 抽象对象很重要,无论抽象对象是否作为 接口或超类不那么重要。推迟 这种命名方式很好地支持接口和超类,使您 如果有必要的话,以后可以自由地改变主意。

有时,命名具体的类对通信来说比 隐藏接口的使用。在这种情况下,接口名称的前缀为i。如果 调用接口 伊菲尔 ,类可以简单地调用 文件 .

更详细的讨论,买这本书!这是值得的!:)

总是选择myclassa,myclassb-它允许一个很好的alpha排序。

我在开玩笑!

这是一个很好的问题,也是我不久前经历的一些事情。我在工作中对代码库进行了重新组织,在放置什么和调用什么方面遇到了问题。

这个 真实的 问题?

我上课做的太多了。如果你试图坚持 single responsibility principle 这会使所有的事情都变得更美好。而不是一个整体 打印头 你可以把它分解成 页面处理器 , 页面格式化程序 (等等)然后有一个主人 打印机 把所有的一切结合在一起。

在我的重新组织中,这花了我很多时间,但是我最终放弃了很多重复的代码,使我的代码库更加合乎逻辑,并且在将一个额外的方法投入到类中之前,我学到了很多东西:d

我愿意 不 但是,建议将模式名等内容放入类名中。类接口应该很明显(比如隐藏单例的构造函数)。如果类是为通用目的服务的,那么通用名称没有任何错误。

祝你好运!

乔希·布洛赫的精彩演讲 good API design 有一些好的建议:

• 课程应该做一件事并且做得很好。
• 如果一个类很难命名或解释,那么它可能没有遵循前面要点中的建议。
• 类名应该立即传递类是什么。
• 好的名字推动好的设计。

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

如果你的问题是命名一个做了很多不同事情的类,你应该考虑把它分成多个类。

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

如果你坚持一个名字,有时只需说出它 any 半知半解的名字,承诺以后再修改是一个好策略。

不要被命名为瘫痪。是的,名字很重要,但不足以浪费大量时间。如果10分钟内你想不出一个好名字,那就继续。

如果一个好的名字没有出现在我的脑海中,我可能会质疑是否存在更深层次的问题——这门课是否有一个好的目的?如果是,命名应该非常简单。

如果你的“fooprocessor”真的处理foos,那么不要因为你已经有了barprocessor、bazprocessor等而不愿意给它取这个名字。当有疑问时,显然是最好的。其他必须阅读代码的开发人员可能没有使用与您相同的同义词库。

也就是说,对于这个特定的例子,更具体的情况不会受到伤害。”“过程”是一个相当宽泛的词。例如,它真的是一个“fooupdateprocessor”(可能会变成“fooupdater”)吗?你不必对命名太“有创意”,但是如果你写了代码,你可能对它的作用和不作用有了相当好的了解。

最后,请记住,裸类名并不是您和代码的读者都必须继续使用的东西——通常也有名称空间在起作用。这些通常可以为读者提供足够的上下文,以便清楚地了解类的真正用途,即使它的裸名称是相当通用的。