谜之楔子（一）

我感觉自己是个形重于实的家伙，对着自己的代码，总有种打扫的冲动。这种冲动可能来自于《Clean Code》一书，但是为何有冲动去读这本书呢？却又无从考证了。也许是感觉代码写得难看面试过不了（其实面试写黑板程序反而不好意思三五行开一个方法）。不过那种一读之下一拍即合的感觉却非一点外因能够解释。

 

《Clean Code 》本身提供了很好的指导思想，例如让方法短，让类职责少。却缺乏脚踏实地的举例分析。导致到Class一章让人感觉始终无法切中要害，至于Concurrency一章，已是云里雾里了。说Concurrency的经典问题，需要自己reference，介绍Concurrency相关的API，需要自己reference，说Concurrency如何写得清楚又不错，连如何reference都不知道了。这些指导思想对于高手来说可能是独孤九剑，对于菜鸟则是太极三年不伤人的勾当。所以还是得学些“招式”，来运用这些心法，或者用这些心法来指导“招式”的实现吧。这里所谓的招式，就是设计模式。

 

于是我接触的下一本书是有名的“K书”《Java与模式》。一读之下却对这本页数上K的经典颇为失望。且不吐槽西游记类比，单就模式本身的介绍而言，此书承袭了中文教材一贯的风格：述其然而不述其所以然。每种模式，都要用穷举法列举所有的形式，但是其分析却近乎没有。其实也不能说是没有分析吧，它的分析集中在前头介绍各种设计原则的章节中。只是这样来回reference的方式确实不是一个好的内容组织形式，因为经过穷举式的洗脑之后，我的脑子里只有那一个个UML图，对若干章节前述的设计原则是在是无法回想，也无力去回想了。实际上那些迪米特原则啊，啥啥啥原则，也是以“穷举原则”一股脑介绍的，无力

 

因此K书本身只能作为一个词典，当我觉得代码中某种某些结构变得急需清理的时候，就会凭字面理解查几个模式看看，能不能帮到自己。至于如何从穷举中选择一个合适的做法，或者自己取其意，还得看实际情况。

 

所谓招是死的，人是活的，其实两本书的融合才是正道， 用K书来指导代码的组织结构，《Clean Code》来提供同等设计下更易读的代码；《Clean Code》来让你感觉到我的代码需要清理，K书告诉你清理的方式。这个分类，也是为融合这一目的挖的大坑。坑里就填一些接触到的设计模式相关的话题。讨论针对Java语言来进行。

 

希望能够细水长流吧。