当我在做“整洁代码”培训或和同事讨论问题时，这样的争端会一遍一遍的出现：
“如果我把我的代码全部拆分成这样的小方法和小类，那我怎么在这么多东西中找一个想要的东西？我需要在几十上百个文件中找来找去！”
这种观点是有问题的，并不是他们说的不对。并且我的确有为了弄懂一个流程而在一堆的小类中仔细翻查代码的经历。
如果你想彻底的理解一段代码，如果所有代码都能放在一起出现在屏幕上，这当然是***的。你可以从顶部到底部一行一行的看完。如果这些代码是拆分在大量的小方法和小类中，你需要跟踪哪个方法来自哪个类，无形中增加了工作量。
但我仍然认为这种观点是错误的。问题在于，这种观点的前提是你想去彻底的了解这些所有代码。
可如果你想从一个更高层的视角，一个抽象的视角看你的代码，那这种拆分是必不可少的。你不可能把所有的知识都放在你的大脑里。当遇到一个不是那么简单的编程任务时，完全彻底的理解所有的代码是不可行的。
一个现实中的任务通常需要你这样做的：
- 减少你需要理解的代码量
- 尽可能的让代码好理解
这其中的关键就是对代码进行提炼抽象！
让 我来问你一个问题：你是否经常使用HashMap——或你喜欢的语言里等效的类、方法？很可能每天要使用数次，不是吗？但你会经常的去查看HashMap 的源代码吗？估计几乎从来没有过吧！因为我们都知道一个Map能做什么，知道HashMap是map的一个最常用的实现类。这就是所有我们需要知道的。我 们只是去用它。我们知道它的功能用法。我们知道当它被使用时会发生什么。
如果你能将你的方法和类进行像这样的提炼抽象，大多数时候你根本不需要去看这些提炼出来的源代码。你只需要看到它的名字就知道它在做什么。也许你不知道它是如何实现的，但你已经知道如何使用它，如果你真的需要深入这些代码研究，这个时候你才会遇到我们上面说的那种情况。
当然，如果你的方法和类不能像HashMap那样明了易懂，这说明它还有改进它的空间。
原文链接：http://blog.schauderhaft.de/2014/01/05/tons-of-small-classes/
