多如牛毛的小类

当我在做“整洁代码”培训或和同事讨论问题时,这样的争端会一遍一遍的出现:

“如果我把我的代码全部拆分成这样的小方法和小类,那我怎么在这么多东西中找一个想要的东西?我需要在几十上百个文件中找来找去!”

这种观点是有问题的,并不是他们说的不对。并且我的确有为了弄懂一个流程而在一堆的小类中仔细翻查代码的经历。

多如牛毛

如果你想彻底的理解一段代码,如果所有代码都能放在一起出现在屏幕上,这当然是最好的。你可以从顶部到底部一行一行的看完。如果这些代码是拆分在大量的小方法和小类中,你需要跟踪哪个方法来自哪个类,无形中增加了工作量。

但我仍然认为这种观点是错误的。问题在于,这种观点的前提是你想去彻底的了解这些所有代码。

可如果你想从一个更高层的视角,一个抽象的视角看你的代码,那这种拆分是必不可少的。你不可能把所有的知识都放在你的大脑里。当遇到一个不是那么简单的编程任务时,完全彻底的理解所有的代码是不可行的。

一个现实中的任务通常需要你这样做的:

  1. 减少你需要理解的代码量
  2. 尽可能的让代码好理解

这其中的关键就是对代码进行提炼抽象!

让我来问你一个问题:你是否经常使用HashMap——或你喜欢的语言里等效的类、方法?很可能每天要使用数次,不是吗?但你会经常的去查看HashMap的源代码吗?估计几乎从来没有过吧!因为我们都知道一个Map能做什么,知道HashMap是map的一个最常用的实现类。这就是所有我们需要知道的。我们只是去用它。我们知道它的功能用法。我们知道当它被使用时会发生什么。

如果你能将你的方法和类进行像这样的提炼抽象,大多数时候你根本不需要去看这些提炼出来的源代码。你只需要看到它的名字就知道它在做什么。也许你不知道它是如何实现的,但你已经知道如何使用它,如果你真的需要深入这些代码研究,这个时候你才会遇到我们上面说的那种情况。

当然,如果你的方法和类不能像HashMap那样明了易懂,这说明它还有改进它的空间。

[英文原文:Tons of Small Classes ]
分享这篇文章:

3 Responses to 多如牛毛的小类

  1. edward32tnt says:

    对于没有IDE的人来说是场灾难

  2. 攻城狮 says:

    没IDE,你赢了

  3. silence_001 says:

    针对接口编程 外观模式,我能想到的。向着这方面努力

发表评论

邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据