因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。

带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?


当前回答

线程1:

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

线程2:

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

这里没有Thread.sleep(…)。

其他回答

这很困难,这是好事。它迫使你思考这个问题,以及这门课实际上应该做什么。好的名字有助于产生好的设计。

不,调试对我来说是最困难的事情!: -)

不仅仅是命名一个类,创建一个适当的包结构可能是一个困难但有益的挑战。您需要考虑分离模块的关注点,以及它们与应用程序愿景的关系。

现在考虑应用的布局:

应用程序 VendorDocRequester(从web服务读取并提供数据) VendorDocViewer(使用请求程序提供供应商文档)

我冒昧地猜测,在一些课程中发生了很多事情。如果你将其重构为一种更加mvc化的方法,并允许小类处理单独的任务,你可能会得到如下结果:

应用程序 VendorDocs 模型 文档(保存数据的普通对象) WebServiceConsumer(处理web服务中的细节) 控制器 DatabaseAdapter(使用ORM或其他方法处理持久化) WebServiceAdapter(利用Consumer抓取文档并将其插入数据库) 视图 HelpViewer(使用DBAdapter输出文档)

然后,类名依赖于名称空间来提供完整的上下文。类本身可以固有地与应用程序相关,而不需要显式地这样说。因此,类名更简单,更容易定义!

另一个非常重要的建议:请帮自己一个忙,拿起一本《Head First Design Patterns》。这是一本非常棒的,易于阅读的书,将帮助您组织应用程序并编写更好的代码。欣赏设计模式将帮助您理解您遇到的许多问题已经得到解决,并且您将能够将解决方案合并到您的代码中。

你现在所做的很好,我强烈建议你坚持你当前的语法,是:

语境+动词+ how

我使用这个方法来命名函数/方法,SQL存储过程等。通过保持这种语法,它将使你的智能感知/代码窗格更加整洁。你需要EmployeeGetByID() EmployeeAdd() EmployeeDeleteByID()当您使用更符合语法的语法(如GetEmployee()、AddEmployee())时,您会发现如果在同一个类中有多个get,情况会变得非常混乱,因为不相关的东西会被分组在一起。

我把它比作用日期命名文件,你想说2009-01-07.log而不是1-7-2009.log,因为在你有了一堆之后,顺序就完全没用了。

当每个合理的名字看起来都太长或不明确时,你可以尝试使用一些不太合理的名字,例如:

类GoForHelpLassie 类DunnoAskTechSupport RTFVM类[V为Vendor]

确保名称是唯一的,并且在类的顶部有一个描述性注释,因为任何在代码中看到它的人都需要查找它来找出它是做什么的(但是当他们这样做时,他们可能会发现它更容易记住)。