因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
当前回答
我学到的一个教训是,如果你找不到一个类的名字,那么这个类几乎总是有问题:
你不需要它 它做的太多了
其他回答
这对我来说通常是很自然的。我总是创建非常短的方法,从不超过6行Smalltalk代码(自动格式化),所以我说这个方法是关于什么的真的没有任何困难。
有时类名很困难,因为我想选择的单词在系统的某个地方正在使用,因为有时同一个单词在不同的上下文中有不同的含义。我希望在这些情况下,允许一些类似维基百科的语法,这样我就可以将我的类命名为“Task (To do list item)”。在这是合法的之前,我用了一个很大的德语风格的单词:ToDoListItemTask。您可能已经猜到了:我的方法名也可以很长。但我认为它们是可读的。
所以,在你的例子中,你的类是一个“getter”,或检索器,或其他什么。你确定这应该在课堂上模仿吗?难道供应商文档不应该请求自己吗?类似于vendorDoc.requestFrom(source);说出名字就容易多了,不是吗?
欢呼,
niko
我不得不承认命名是一门艺术。如果你的类遵循特定的“设计模式”(工厂等),事情就会变得简单一些。
在“一个词”中总结方法/类,回答它的意思是什么? 这个词应该没有对应的词。
上个月我刚刚写了一篇关于命名惯例的文章:http://caseysoftware.com/blog/useful-naming-conventions
要点是:
verbAdjectiveNounStructure -结构和形容词作为可选部分
对于动词,我坚持使用动作动词:保存、删除、通知、更新或生成。偶尔,我也会使用“进程”一词,但只是专门指队列或工作积压。
对于名词,我使用与之交互的类或对象。在web2project中,这通常是任务或项目。如果是Javascript与页面交互,则可能是body或table。关键在于代码清楚地描述了与之交互的对象。
该结构是可选的,因为它对该情况是惟一的。列表屏幕可能会请求List或Array。在web2project的项目列表中使用的核心函数之一就是getProjectList。它不修改底层数据,只修改数据的表示形式。
The adjectives are something else entirely. They are used as modifiers to the noun. Something as simple as getOpenProjects might be easily implemented with a getProjects and a switch parameter, but this tends to generate methods which require quite a bit of understanding of the underlying data and/or structure of the object... not necessarily something you want to encourage. By having more explicit and specific functions, you can completely wrap and hide the implementation from the code using it. Isn't that one of the points of OO?
这很困难,这是好事。它迫使你思考这个问题,以及这门课实际上应该做什么。好的名字有助于产生好的设计。