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

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

<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --><!--END RESERVED FOR FUTURE USE INCLUDE FILES-->

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、再谈设计模式的动机

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

设计模式本身的动机往往是领域无关的，但是我们重构到设计模式的动机却往往是领域相关的。因为我们重构的主要目标是要达到能够很好的展示我们的设计意图，而这些设计意图往往和问题领域的上下文关系密切。

比如：Factory Method设计模式的意图是定义一个创建对象的接口，让子类来确定到底实例化哪个类，Factory Method方法使得一个类的实例化时机延迟到子类中。但是我们在重构的过程中何时决定使用Factory Method设计模式呢？基本上是因为一个类的构造方式有多种，每一种都有不同的含义，但是构造函数的名字是唯一的，通过同样的构造函数名，赋予不同的参数的方法来实例化对象的方式，使得使用者很难理解这个构造函数的真正含义。所以通过使用Factory Method设计模式，定义不同的用于展示具体意图的函数名称来实例化对象，就更加能够展示使用者的意图。另外，该模式还简化了该类的构造方式，封装了该类的实例化细节。

参考文献〔2〕中有很多这方面的实例，大家可以下载下来阅读一下，相信会有更大的收获。

6、结论

本文结合设计模式探讨了在进行程序结构改善的过程中，容易造成的误解：即过分的关注程序结构的灵活性。这样做很容易从是否能够给设计带来灵活性的角度来进行程序结构的重构，最终可能造成系统的复杂、混乱、不易理解、难以维护，从而导致项目失败。其实一个好的程序结构根本不在于其中使用了多少设计模式、多么具有弹性，主要在于该结构是否能够非常清晰的展现设计者的意图（可以参考参考文献〔1〕）。由于在很多情况下，通过引入设计模式可以很好的做到这一点，所以设计模式往往会成为重构的目标，但是有一点要记住：不要过早的引入设计模式，要让它在重构的过程中自然浮现出来。

参考资料

[1] To Be Explicit，Martin Fowler, IEEE Software Vol.18 No.6

[2] Refactoring To Patterns, Joshua Kerievsky, industriallogic.com

[3] Is Design Dead, Martin Fowler, www.martinfowler.com