你用来描述问题的语言，就是你应该用来描述变量、方法、对象、类等的语言。一般来说，名词匹配对象，动词匹配方法。如果您缺少描述问题的词语，那么您也缺少对问题的全面理解(规范)。

如果它只是在一组名称中进行选择，那么它应该由您用来构建系统的约定来驱动。如果您遇到了以前的约定所没有发现的新情况，那么总是值得花一些精力尝试扩展它们(适当地、一致地)来覆盖这个新情况。

如果有疑问，那就睡一觉，选一个最明显的名字，第二天早上:-)

如果有一天你醒来发现自己错了，那就马上改变。

保罗。

BTW: Document.fetch()是非常明显的。

不要忘记设计模式(不仅仅是GoF模式)是一种提供公共词汇表的好方法，只要适合情况，就应该使用它们的名称。这甚至可以帮助熟悉命名法的新手快速理解体系结构。您正在处理的这个类是否应该充当Proxy，甚至是Façade ?

我发现一旦事情完成了，选择一个名字就更容易了。重构- >重命名增值。

线程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(…)。

简而言之: 我同意好名字很重要，但我不认为你必须不惜一切代价在实现之前找到它们。

当然，最好一开始就有个好名字。但如果你不能在2分钟内想出一个，以后重命名将花费更少的时间，从生产力的角度来看是正确的选择。

长: 一般来说，在实现之前对名称考虑太久通常是不值得的。如果你实现你的类，命名它为“Foo”或“Dsnfdkgx”，在实现的时候，你会看到你应该给它命名什么。

特别是在Java+Eclipse中，重命名一点也不麻烦，因为它会小心地处理所有类中的所有引用，并警告您名称冲突等。只要这个类还没有在版本控制存储库中，我不认为重命名5次有什么错。

基本上，这是一个如何思考重构的问题。就我个人而言，我喜欢它，尽管它有时会惹恼我的队友，因为他们相信永远不要碰一个运行系统。从您可以重构的所有内容来看，更改名称是您可以做的最无害的事情之一。

我觉得这不难。如果你叫不出名字，也许你就不需要它。你的设计越好，你就越容易为你的设计命名。

现在来看临时变量，这是另一回事了。：）