提出好的,准确的课程名称是众所周知的困难.如果做得好,它会使代码更加自我记录,并提供一个词汇表来推断更高抽象级别的代码.
实现特定设计模式的类可以根据众所周知的模式名称(例如FooFactory,FooFacade)给出一个名称,直接模拟域概念的类可以从问题域中获取它们的名称,但是其他类呢？当我缺乏灵感,并且想避免使用泛型类名(如FooHandler,FooProcessor,FooUtils和FooManager)时,有什么类似于程序员的词库吗？
我将引用Kent Beck的Implementation Patterns的一些段落:
"[...]名称应该简短而有力.然而,为了使名称精确有时似乎需要几个词.摆脱这种困境的一种方法是选择一个强有力的计算隐喻.用一个比喻记住,甚至单词带来了丰富的关联,连接和含义网络.例如,在HotDraw绘图框架中,我在绘图中对象的第一个名字是 DrawingObject.Ward Cunningham出现了排版隐喻:绘图就像一个打印的布局页面.页面上的图形项目是数字,因此该类成为图形.在隐喻的上下文中,图形 同时比DrawingObject更短,更丰富,更精确."
"子类的名称有两个作业.它们需要传达它们是什么类以及它们是如何不同的.[...]与层次结构根源的名称不同,子类名称在对话中几乎不常使用,所以他们可以以简洁为代价表达.[...]
将作为层次结构根的子类赋予其自己的简单名称.例如,HotDraw有一个Handle类,它在选择图形时显示图形编辑操作.简单地说, 尽管扩展了图,它仍然是Handle.有一整套手柄,它们最适合像StretchyHandle和TransparencyHandle这样的名字 .因为Handle是它自己的层次结构的根,所以它比一个合格的子类名更值得一个简单的超类名.
子类命名的另一个缺点是多级层次结构.[...]而不是盲目地将修饰符添加到直接超类中,从读者的角度考虑名称.他需要什么课才能知道这堂课是什么样的？使用该超类作为子类名称的基础."
两种类型的命名接口取决于您如何考虑接口.作为没有实现的类的接口应该被命名为它们是类(简单超类名称,合格子类名称).这种命名方式的一个问题是,在命名类之前,好的名称已经用完了.名为File的接口需要一个名为ActualFile,ConcreteFile或(yuck!)FileImpl的实现类 (后缀和缩写).通常,无论是将抽象对象实现为接口还是超类都不太重要,无论是处理具体对象还是抽象对象进行通信都很重要.延迟界面和超类之间的区别很好地支持这种命名方式,如果有必要,您可以在以后随意改变主意.
有时,命名具体类对于通信而言比隐藏接口的使用更为重要.在这种情况下,前缀接口名称为"I".如果接口名为IFile,则该类可以简单地称为File.
有关更详细的讨论,请购买本书!这很值得!:)
总是去MyClassA,MyClassB - 它允许一个不错的alpha排序..
我在开玩笑!
这是一个很好的问题,也是我不久前经历过的事情.我在工作中重新组织我的代码库,并且在哪里放置什么以及它叫什么都有问题.
在真正的问题？
我上课的时间太多了.如果你试图遵循单一责任原则,它将使所有内容更好地结合在一起.而不是一个单片PrintHandler类,你可以将它分解为PageHandler,PageFormatter(等等),然后有一个主打印机类,将它们汇集在一起.
在我的组织中,我花了很多时间,但是我最终将很多重复的代码分类,让我的代码库更加合理,并且在考虑在类中抛出额外的方法之前进行思考时学到了很多东西:D
但是,我不建议将类似名称的内容放入类名中.类接口应该显而易见(比如隐藏单例的构造函数).如果类正在服务于通用目的,则通用名称没有任何问题.
祝好运!
Josh Bloch关于良好API设计的精彩演讲有一些很好的建议:
课程应该做一件事,做得好.
如果一个类很难命名或解释,那么它可能不遵循上一个要点中的建议.
类名应立即传达类的内容.
好名字推动了良好的设计.
如果您的问题是如何命名暴露的内部类,也许您应该将它们合并为更大的类.
如果你的问题是命名一个做很多不同东西的类,你应该考虑把它分成多个类.
如果这对于公共API是一个很好的建议,那么它对任何其他类都不会有害.
如果你坚持使用一个名字,有时只是给它任何半懂的名字,并承诺稍后修改它是一个很好的策略.
不要命名瘫痪.是的,名字非常重要,但它们不足以浪费大量时间.如果你不能在10分钟内想出一个好名字,继续前进.
如果一个好名字不会浮现在脑海中,我可能会质疑是否存在更深层次的问题 - 这个课程是否有用？如果是这样,命名它应该非常简单.
京公网安备 11010802040832号 | 京ICP备19059560号-6 