给类取个好、准确的名称是非常困难的。如果做得好,它可以使代码更加自我说明,并提供一个用于高层次抽象理解代码的词汇表。
实现特定设计模式的类可以根据其已知模式名称(例如 FooFactory、FooFacade)进行命名,而直接模拟领域概念的类可以从问题域中获取名称,但其他类如何处理呢?是否有像程序员同义词词典那样的东西,当我缺乏灵感时可以翻阅,避免使用通用类名称(例如 FooHandler、FooProcessor、FooUtils 和 FooManager)?
给类取个好、准确的名称是非常困难的。如果做得好,它可以使代码更加自我说明,并提供一个用于高层次抽象理解代码的词汇表。
实现特定设计模式的类可以根据其已知模式名称(例如 FooFactory、FooFacade)进行命名,而直接模拟领域概念的类可以从问题域中获取名称,但其他类如何处理呢?是否有像程序员同义词词典那样的东西,当我缺乏灵感时可以翻阅,避免使用通用类名称(例如 FooHandler、FooProcessor、FooUtils 和 FooManager)?
"[...] 名称应该简短而有力。但是,为了使名称精确,有时似乎需要几个词。摆脱这种困境的方法是选择一个强大的计算机隐喻。有了隐喻,即使是单词也带来了丰富的联想、联系和含义。例如,在HotDraw绘图框架中,我对于绘图对象的第一个名称是DrawingObject。Ward Cunningham提出了排版隐喻:绘图就像一张印刷、布局好的页面。页面上的图形项是图形,因此该类变成了Figure。在隐喻的背景下,Figure比DrawingObject同时更短、更丰富和更精确。"
始终选择MyClassA、MyClassB-它可以进行良好的按字母排序..
我开玩笑的!
这是一个好问题,也是我不久前遇到的问题。我正在重新组织我的工作代码库,并且在放置什么以及如何命名方面遇到了问题。
真正的问题是什么?
我的类做了太多事情。如果您尝试遵循单一职责原则,它将使所有内容更加协调。而不是一个臃肿的PrintHandler类,您可以将其拆分为PageHandler,PageFormatter(等等),然后有一个主Printer类将所有内容汇集在一起。
在我的重新组织中,我花费了一些时间,但最终处理了大量重复的代码,让我的代码库更加合理,并学会了在向类中添加额外方法之前先思考的东西:D
然而,我不建议将像模式名称之类的内容放入类名中。类的接口应该显而易见(例如隐藏单例构造函数)。如果类提供通用目的,则使用通用名称是没有问题的。
祝你好运!
Josh Bloch的一次有关良好API设计的优秀演讲提供了以下几点建议:
如果您的问题是如何为公开的内部类命名,也许您应该将它们合并成更大的类。
如果您的问题是为正在执行多种不同任务的类命名,则应考虑将其拆分成多个类。
如果这对于公共API是一个好主意,那么对于任何其他类都不会有坏处。