因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
当前回答
Leo Brodie在他的书《Thinking Forth》中写道,对于程序员来说,最困难的任务是为事物命名,他指出最重要的编程工具是同义词词典。
试着使用http://thesaurus.reference.com/上的同义词典。
除此之外,不要使用匈牙利符号,避免缩写,并保持一致。
最好的祝福。
其他回答
DocumentFetcher吗?没有上下文很难说。
它可以帮助你像数学家一样,在你的领域中借用/发明一个词汇:使用简短的简单的词来暗示概念,而不是每次都拼写出来。我经常看到长拉丁短语变成首字母缩略词,让你需要一本字典来了解这些首字母缩略词。
不仅仅是命名一个类,创建一个适当的包结构可能是一个困难但有益的挑战。您需要考虑分离模块的关注点,以及它们与应用程序愿景的关系。
现在考虑应用的布局:
应用程序 VendorDocRequester(从web服务读取并提供数据) VendorDocViewer(使用请求程序提供供应商文档)
我冒昧地猜测,在一些课程中发生了很多事情。如果你将其重构为一种更加mvc化的方法,并允许小类处理单独的任务,你可能会得到如下结果:
应用程序 VendorDocs 模型 文档(保存数据的普通对象) WebServiceConsumer(处理web服务中的细节) 控制器 DatabaseAdapter(使用ORM或其他方法处理持久化) WebServiceAdapter(利用Consumer抓取文档并将其插入数据库) 视图 HelpViewer(使用DBAdapter输出文档)
然后,类名依赖于名称空间来提供完整的上下文。类本身可以固有地与应用程序相关,而不需要显式地这样说。因此,类名更简单,更容易定义!
另一个非常重要的建议:请帮自己一个忙,拿起一本《Head First Design Patterns》。这是一本非常棒的,易于阅读的书,将帮助您组织应用程序并编写更好的代码。欣赏设计模式将帮助您理解您遇到的许多问题已经得到解决,并且您将能够将解决方案合并到您的代码中。
我发现局部变量最麻烦。例如,我想创建一个DocGetter类型的对象。我知道它是DocGetter。为什么我要给它另一个名字?我通常会给它起一个像dg(用于DocGetter)或temp之类的名字,或者其他同样没有描述性的名字。
该类只有一个合理的名称:
HelpRequest
不要让实现细节分散了你对意义的注意力。
这很困难,这是好事。它迫使你思考这个问题,以及这门课实际上应该做什么。好的名字有助于产生好的设计。