解耦合手段之一：DRY原则

一直信誓旦旦的要总结一下软件系统解耦合的手段。等到真的要写了，才发现这可不是件容易的事情。所谓解耦合，也就是解开系统内各模块间不必要或不合理的依赖关系，让各个模块内部结构紧凑，整体架构简化从而易于理解和维护，方便扩展。目标就是“高内聚，低耦合”。软件系统中的耦合，说远了可能是软件开发团队的组织结构和管理造成的，说近了也可能是你键盘上的Ctrl+C、Ctrl+V造成的。我打算想到哪里就写到哪里，一次写一个方法。

首先想到的自然是DRY原则了。DRY原则，全称是Don't Repeat Yourself 原则，有人翻译做“一次且仅此一次”原则，其实就是“不要重复”。这句话也是著名的《程序员修炼之道》中的核心原则之一。

信息不应重复。因为重复的信息给将来的改动带来困难，使得系统更复杂，并且可能导致将来的不一致性。比方说有一段代码我写好了，然后发现另外一个地方也要用，于是我就把它拷贝过去，结果就造成了代码上的重复。等到下次我要改的时候就要改两个地方。也可能下次不是我改了，而改的那个人不知道另一段相同内容、相同目的的代码的存在，只改了一个地方。比这个例子还要糟糕许多的真实情形每天都在我们的软件开发组织里发生着。

比方说我们常听说的所谓“详细设计文档”往往就是对代码的重复。一批又红又专的程序员写了代码，然后又把代码中所写的内容记录在文档里，虽然他们不知道为啥要这样做（当然，他们也可能先写的文档，再写代码，那只会更糟）。后来来了一批不那么红，不那么专的程序员，改了代码没补文档。再后来大家就不知道该信文档还是该信代码了。如果那批又红又专的程序员知道，代码不光是写给编译器看的，也是写给人看的，就不会把精力放在不该放的地方了。听到这个，总会有更红更专的老程序员跳出来大叫：“咄！不做设计就写代码，成何体统！”没人说不让你做设计，且不说万恶的BDUF（Big Design Up-Front），就说简单的设计吧，你把它写在白板上，画在纸上不是也一样么。然后把它用代码清晰的描述出来。最后别忘了把白板擦了，把那张纸吃掉，省得留下来害人。

还有，测试文档往往是对自动化测试脚本的重复；需求分析文档往往是对验收测试的重复。。。。。。

为了发现和剪除代码中的重复，有专门的CPD（Copy-Paste Detector）工具可以用。我用过一个叫PMD的开源软件，很不错，支持Java, C/C++, PHP。把它用在我们的一些代码上，有时你会发现几十处，每处上百行的重复代码。我想，这足够说明问题的了。

几乎软件中所有的问题都和重复有关，而软件设计中用到的各种原则，最后其实也就是用来减少重复的。《Clean Code》里面说：“Duplication may be the root of all evil in software.”这话说得可能大了点，看你如何来理解了。像我那位狡猾的以色列朋友在听到有人夸他们犹太人都很有经济头脑时常说的：

“All generalizations are wrong, including this one.” :-)