重构 - 理解设计模式的捷径（2 背景简介）

 

第2章 背景简介

2.1 软件需求的介绍

由于大学期间是利用这个小游戏来参加软件设计大赛的，所以姑且先叫它“产品”吧。这样好像更加正规一些。软件名为“勇敢者游戏” ，功能需求之类的都是老师规定好了。还是先把需求简要介绍一下，方便之后的分析。

以下引自该软件的需求规格说明书：

“勇敢者”是一个角色扮演类视频游戏，它面向较成熟的用户。

该游戏实现的具体功能如下：

1．人物：本游戏共有两种类型的人物，分别为被玩家所控制的玩家人物和由系统所控制的外部人物。当前版本中，这两种人物为各1 个。人物的属性分为耐力、力量、耐心、智力、注意力5 项，其总和为生命值，当生命值为0 时人物死亡，游戏结束。游戏初始时，玩家可为自己控制的玩家人物分配5 项属性值，其总和必须小于等于100，而外部人物的5 项属性初始均为20。

2．环境：游戏的环境即为游戏人物可以移动的范围，为如下6 个区域：更衣室、厨房、院子、地牢、起居室、书房。每相邻两区域之间都有通道连接。每个区域都有自己的属性，对应于人物5 种属性中的若干种。更衣室为无属性，厨房的属性为注意力，院子为耐力、力量，起居室为耐力、注意力，地牢为耐力、耐心，书房为智力。当玩家在一个区域时，在边缘显示通道(图中粗线条)的超链接，点击超链接可显示链接所在区域中的人物。

3．人物移动：玩家人物的移动由玩家控制，当玩家人物单独处于某一区域时，可以重新分配自己人物的属性值，但是受到一定限制：可以增加某一项属性值，其他属性相应平均降低，而且总值小于等于原来的总值；重新分配后的属性值4秒 后生效，如果4秒内发生战斗，那么属性分配取消。系统人物可以在相邻的区域自由移动。

4．人物遭遇战：当两个人物同时出现在一个区域中时触发战斗。当交战发生时，两个人物中的“强者”指的是所在区域属性值较大的一方。系统会把“弱者”的该区域相应属性能力值的一半转给强者。如果没有强者，那么不会发生数值转移。重新分配后如果任何一个人的生命值为0，那么游戏结束，否则，系统人物被移动到其他区域，并显示交战结果。

2.2 重构软件

可以看到，此软件的功能需求还是比较简单的。如果仅仅是为实现功能的话，甚至不用任何一个设计模式都可以实现，直接用面向过程的开发方式。笔者第一次做类似的程序的时候就是把所有的功能都写到了一个类里面（开发环境用的经典的VC 6.0），也就是视图类，所有的属性，功能，全部都写在视图中。这样视图层和业务逻辑层完全没有分离（暂时弹不上持久层，因为当时的程序没有任何需要持久化的数据），代码看起来混乱不堪，流程控制多而复杂，更弹不上维护了。一旦要引入新的功能，所修改的工作量几乎等于重写全部代码。

所以，在拿到这个程序的时候，所想到的第一件事就是应该要自己写点“类”了。也就是利用面向对象封装的思想，这样至少可以分离一些东西了。不过限于当时的设计水平，整个程序写下来整体还是没有体现多少OO思想，几乎80%的职责还是由视图类完成的。除了有几个自己写的类之外。不过，由于功能比较完善（相对于其他的参赛小组），这个小程序还是得了一等奖（窃喜一下）。

时过境迁，现在到了华科，也深入地学习了一两个设计模式，于是开始考虑这个程序是不是用OO思想重构一下更好。所以就把程序重新翻出来研究了一下。好在自己编程习惯比较好，变量命名的规范性、程序的可读性、必要的注释等，当时还是做的可以，所以再看的时候并没有太费力。研究的结论就是：需要重构的地方太多太多了。于是花了几个通宵来“再生产”这段接近5000行的小程序。期间加入几种设计模式：简单工厂模式，单例模式，状态模式，备忘录模式。当然，这些模式还是次要的，关键是有很多地方利用面向对象“多态”的特性重新设计了。有人说会用多态才算是真正跨入了面向对象的门槛。这句话现在看起来一点都不假，因为只有多态才可以最大限度地增加程序的灵活性和扩展性，方便之后的维护工作。最重要的是，通过重构，笔者才第一次真正从实际的程序中体会到了设计模式的威力。“了解模式的演化过程远比了解模式本身要重要” ，这句话的确道出了学习模式的切入点和捷径所在。接下来笔者就以自己重构的过程为切入点，逐步介绍期间所采用的几种设计模式。