使用设计模式改善程序结构（三）

核心提示：设计模式在某种程度上确实能够改善我们的程序结构，使设计具有更好的弹性，使用设计模式改善程序结构（三），也正是由于这个原因，会导致我们可能过度的使用它，现在我们有两个动机存在，设计模式本身的动机以及我们要重构来改善我们的程序结构的动机（可能是要重构到一个设计模式），程序结构具有过度的、不必要的灵活性和程序结构没有灵活性一

设计模式在某种程度上确实能够改善我们的程序结构，使设计具有更好的弹性。也正是由于这个原因，会导致我们可能过度的使用它。程序结构具有过度的、不必要的灵活性和程序结构没有灵活性一样都是有害的。本文将分析过度的灵活性可能造成的危害，并且结合一些实例来阐述使用设计模式改善程序结构应遵循的原则。

1、介绍

本系列文章的前两篇主要讲述了如何使用设计模式来改善我们的程序结构，大家可以看到经过调整的代码具有了更大的弹性，更轻易适应变化。读者朋友可能也具有类似的经验，通过使用设计模式使得自己的软件系统更加具有可扩展性和健壮性。但是，这样就可能会造成一个结果：无论碰到任何问题，我们首先做的就是设法找到一个解决它的设计模式来，而不是解决问题的最简洁的方法。

上面所述的就是过分使用设计模式的情况，它赋予了代码过度的灵活性。大家往往对于僵化、拙劣的设计所导致的危害非常清楚，但是对于过度灵活的设计可能带来的危害却不是很重视。本文试图从这个角度来谈谈使用设计模式改善程序结构应遵循的原则，使大家避免陷入过分使用设计模式的状况。其中的一个要害议题就是：我们为什么要使用设计模式，到底什么样的程序结构才是好的。

2、过分设计的危害

正是由于大家对于僵化的设计所造成的结果的惧怕，以及对于设计模式给我们的程序结构带来的无比的弹性的赞叹，才会导致过分的预先设计（up-front design）。原因很简单：需求肯定是要变化的。所以，我们就需要给代码一些更多的灵活性，使得它可以适应以后的变化。于是，我们在最开始的设计中，就针对需求的变化做了很多的假设，并把对于这些假设的支持放在代码中。

假如对这些假设的猜测是正确的，那么做的这一切都是值得的。不幸的是，对这些假设的猜测很难是正确的。原因很简单：需求是我们的客户（一般是另外一个企业）提出的，但是作为一个现代的企业，要想生存，就要不断的改变自己以适应日新月异的变化，所以客户的需求肯定是要根据自身生存、发展的需要而不断变化的，并且这些变化都是很难猜测的，经常是客户自己都不知道下一步该如何变化（假如都能够被你猜测到的话，这个公司肯定会高薪聘请你去做他们的CEO）。

假如猜测是错误的话，第一个直接后果就是，浪费了宝贵的时间、资金。我们花了很多的时间在一些根本没有任何用处的灵活性上，而这些时间本可以用来为系统增加新的功能或者修正错误。

过分灵活的代码往往更加复杂、难以理解。其他的开发人员不得不花费很多的时间来理解这些本来可以去除的复杂性。必然导致代码的维护、扩展困难（假如需求的变化和你的假设不同），项目的开发效率降低。

例如：发现一种计算有多个不同的方式， 不加思考就直接采用Strategy设计模式，而不是采用简单、清楚的条件表达式的方法（if－else语句），那么就会导致结构的复杂（要增加好几个类）。假如后来发现根本就没有在增加新的计算方法方面的需求，或者更糟糕的是需求的变化是某几个计算策略间要增加依靠关系，那么修改起来就会十分困难。系统中假如存在太多的这种没有必要的灵活性，很可能最终的程序结构就会陷入冗余、混乱之中。

程序结构的灵活性是有代价的，这种代价往往是更多的复杂性或者造成系统不轻易理解，需要我们在设计时进行权衡。

3、软件开发的节奏

现在在软件工程领域很活跃的一个组织是：灵敏社团，他们提出了一系列的灵敏方法（XP就是其中很闻名的一种）。在灵敏方法中制定了一系列的策略、实践来拥抱需求的变化。其目标是：使软件以规范的节奏进展，最终保质、按时交付软件产品。现在已有很多使用这种方法成功的商业案例。

对于软件开发的节奏可以描述如下：首先写测试代码，提出对于系统的功能需求，然后写工作代码满足这个需求，重复这个过程直到实现系统的所有需求。在这个过程中间要频繁的（一般是在增加新功能或者修正错误时）进行重构，去除冗余的、含糊的代码，改善程序的结构，使得新功能的添加变得轻易。可以看出在这样的软件开发节奏中，没有对需求的变化做什么猜测（进行猜测的主要原因是惧怕变化），而是以一种主动的姿态来拥抱变化，当目前的设计不能够适应发生的变化时，大胆的进行重构（因为有频繁测试保证，所以重构的风险是不大的）去适应新的变化。这种方式被称为演化设计（evolutionary design），在参考文献〔3〕中可以得到进一步的内容。

设计模式一般会成为重构的目标，但是为什么要这样做？我们一定要重构到一个设计模式吗？怎样的程序结构才是好的呢？

4、要害是要展现设计意图

现在有一个普遍的误解就是：程序结构的灵活性越高越好，所以对程序结构改善的目标就是使它具有更高的弹性，这样在未来需求发生变化时可以很轻易的改变程序来适应这种变化。其实，结构的灵活性和结构的易更改性之间是有矛盾的。很明显，结构越灵活相应的就会越复杂，越复杂就越不轻易理解，不轻易理解怎么会轻易更改呢？参考文献〔1〕中专门探讨了这个问题，有爱好可以看看。

正是这个误解的存在，使得很多开发者看到了设计模式所带给程序结构的灵活性，从而在进行代码重构时就把结构的灵活性作为一个最重要的目标。最终导致了程序结构的过分灵活性，损伤了软件的质量。

但是，设计模式确实能够改善我们的程序结构，面向对象大师Martin Fowler的经典著作《Refactoring ImPRoving the Design of Existing Code》一书中就有很多的使用设计模式进行重构的例子。难道仅仅是因为设计模式能够带来足够的灵活性吗？显然不是！主要是因为这些设计模式更能够展示设计者的设计意图，更加便于理解！

很多面向对象专家和模式研究专家对重构的动机进行了研究，发现对于一个好的重构过程来说，重构的结果到底是不是一个设计模式是不重要的。它们的最终动机都是：减少或者消除冗余代码，简化设计最终达到展示真正的设计意图，更加便于交流。

Martin Fowler的《Refactoring》一书的第一章有一个关于影碟出租的例子，具体的展示了重构的过程以及每一步的动机，很好的说明了上面的问题。

5、再谈设计模式的动机

本系列文章的第一篇中谈论设计模式本身的意图、动机的重要性。这里我想再结合上面的内容重新熟悉一下这个问题。现在我们有两个动机存在，设计模式本身的动机以及我们要重构来改善我们的程序结构的动机（可能是要重构到一个设计模式）。这两个动机其实是没有很大的关系的。