因此,我正在处理这个类,它应该通过web服务从供应商请求帮助文档。我试着把它命名为documententretriver, VendorDocRequester, DocGetter,但它们听起来不太对。最后,我在dictionary.com网站上浏览了半个小时,试图找到一个合适的词。
带着坏名字开始编程就像早上头发很糟一样,接下来的一天就会每况愈下。感觉我吗?
因此,我正在处理这个类,它应该通过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]
确保名称是唯一的,并且在类的顶部有一个描述性注释,因为任何在代码中看到它的人都需要查找它来找出它是做什么的(但是当他们这样做时,他们可能会发现它更容易记住)。