使用设计模式改善程序结构（1）
设计模式是对特定问题经过无数次经验总结后提出的能够解决它的优雅的方案。但是，假如想要真正使设计模式发挥最大作用，仅仅知道设计模式是什么，以及它是如何实现的是很不够的，因为那样就不能使你对于设计模式有真正的理解，也就不能够在自己的设计中正确、恰当的使用设计模式。本文试图从另一个角度（设计模式的意图、动机）来看待设计模式，通过这种新的思路，设计模式会变得非常贴近你的设计过程，并且能够指导、简化你的设计，最终将会导出一个优秀的解决方案。
1、介绍
在进行项目的开发活动中，有一些设计在项目刚刚开始工作的很好，但是随着项目的进展，发现需要对已有的代码进行修改或者扩展，导致这样做的原因主要有：新的功能需求的需要以及对系统进一步理解。在这个时候，我们往往会发现进行这项工作比较困难，即使能完成也要付出很大的代价。此时，一个必须要做的工作就是要对现有的代码进行重构（refactoring），通过重构使得我们接下来的工作变得相对轻易。
重构就是在不改变软件系统代码的外部行为的前提下，改善它的内部结构。重构的目标就是使代码结构更加合理，富有弹性，能够适应新的需求、新的变化。对于特定问题给出美丽解决方案的设计模式往往会成为重构的目标，而且一旦我们能够识别出能够解决我们问题的设计模式，将会大大简化我们的工作，因为我们可以重用别人已经做过的工作。但是在我们的原始设计和最终可能会适用于我们的设计模式间的过渡并不是平滑的，而是有一个间隙。这样的结果就是：即使我们已经知道了很多的设计模式，面对我们的实际问题，我们也没有一个有效的方法去判定哪一个设计模式适用于我们的系统，我们应该去怎样应用它。
造成上述问题的原因往往是由于过于注重设计模式所给出的解决方案这个结果，而对于设计模式的意图，以及它产生的动机却忽略了。然而，正是设计模式的意图、动机促使人们给出了一个解决一类问题的方案这个结果，设计模式的动机、意图体现了该模式的形成思路，所以更加贴近我们的实际问题，从而会有效的指导我们的重构历程。本文将通过一个实例来展示这个过程。
在本文中对例子进行了简化，这样做是为了突出问题的实质并且会使我们的思路更加清楚。思路本身才是最重要、最根本的，简化了的例子不会降低我们所展示的思路、方法的适用性。
2、问题描述
一个完善的软件系统，必须要对出现的错误进行相应的处理，只有这样才能使系统足够的健壮，我预备以软件系统中对于错误的处理为例，来展示我所使用的思路、方法。
在一个分布式的网管系统中，一个操作往往不会一定成功，经常会因为这样或者那样的原因失败，此时我们就要根据失败的原因相应的处理，使错误的影响局限在最小的范围内，最好能够恢复而不影响系统的正常运行，还有一点很重要，那就是在对错误进行处理的同时，一定不要忘记通知系统的治理者，因为只有治理者才有能力对错误进行进一步的分析，从而查找出错误的根源，从根本上解决错误。
下面我就从错误处理的通告治理者部分入手，开始我们的旅程。假定一个在一个分布式环境中访问数据库的操作，那么就有可能因为通信的原因或者数据库本身的原因失败，此时我们要通过用户界面来通知治理者发生的错误。简化了的代码示例如下：
/* 错误码定义 */
class ErrorConstant
{
public static final int ERROR_DBAccess = 100;
public static final int ERROR_COMMUNICATION = 101;
}
/* 省略了用户界面中的其他的功能 */
class GUISys
{
public void announceError(int errCode) {
switch(errCode) {
case ErrorConstant.ERROR_DBACCESS:
/* 通告治理者数据库访问错误的发生*/
break;
case ErrorConstant.ERROR_COMMUNICATION:
/* 通告治理者通信错误的发生*/
break;
}
}
}
开始，这段代码工作的很好，能够完成我们需要的功能。但是这段代码缺少相应的弹性，很难适应需求的变化。
（未完待续）
