使用JavaScript创建模块化的双人对战象棋程序

1. 关于这篇文章

2004年，我花两天时间，用JavaScript和VML创建了一个单机双人象棋，并且作了简短的分析。在那个时代，没有AngularJS，没有BackBone，没有所有这些前端MV*框架。甚至没有jQuery，没有prototype，没有mootools，因此没有什么可借鉴的模块划分方式。我只好用很原始的办法，做了一种伪继承，实际是组合，来实现棋子和棋局之间的关系。

现在是2013年，9年过去了，Web的世界早已不是过去的样子，开发方式发生了翻天覆地的变化，我们有了Gmail，有了Google docs等等把Web技术应用到极致的优秀产品，有了asm.js、pdf.js等等让我们目瞪口呆的技术，更催生了各种MV*框架的兴起，我们有更多，更强大的方式去写Web程序。

前一段时间，我创建了一个简单的JavaScript框架叫做thin，实现了模块的定义、异步加载和使用，并且为它写了一个比较简短的Demo，但这个Demo实在太简单了，当一个应用更大、更复杂的时候，我们应该如何组织自己的程序呢？

为了说明我们这个简单框架的能力，我把之前写过的这个象棋在这个thin框架基础上重写一遍，并且作更深入的分析，以便使一些入门不久的读者得到帮助，同时也顺便检验我的新框架模块化是否是可用的。

另外一个方面，我们看到VML已经彻底衰落了，各种基于SVG和Canvas的绘图技术取代了它，因此在本例中，我们也与时俱进，改用SVG来绘制棋盘和棋子。RaphaelJS是一个很好的跨平台绘图库，它封装了SVG和VML，在能够使用SVG的浏览器中，它用SVG绘图，否则尝试使用VML，对于上层应用，操作绘图的API是毫无区别的，开发者不会感知到它的具体实现差别。

之前我写过一些文字，用于探讨软件开发模块的划分原则，感觉它们放在这篇文章里非常合适，所以略微修改之后，加了进来。

2. 模块划分的一些原则

2.1. 面向对象

面向对象可以算是老生常谈了，在现代软件开发中，它是个主流的选择，相对于面向过程，有一些改进。

假设我们是上帝，要创造世界，因为这个过程太过复杂，无从入手，所以先从一件简单的事情看起。现在我们要设计一个方法，用于描述狼吃羊这个事情，某只狼吃了某只羊，你可以面向过程地吃，eat(狼A, 羊A)，也可以面向对象地吃，狼A.eat(羊A)。差别在哪里？只是写法有点变化。

好，那么我们帮上帝模拟整个生物界，这里面很多东西可以吃，大鱼吃小鱼，小鱼吃虾米，吃不吃皮，吐不吐骨头，这个时候再来修改这个eat函数，复杂吗？eat里面要判断很多东西，假如上帝很勤劳，所有代码都自己设计，那没关系，没太大区别，判断就判断呗。

假设上帝没足够精力来管理整个东西了，雇了一群天使来协助设计，每个人都来修改这个eat函数，当然可以拆分，wolfEatSheep(), tigerEatWolf()，然后在eat里面判断参数来分别调用，把函数分下去让每个人做，可以。

动物不光要做吃这个事情，要能跑能跳，会说会叫，又多了一堆函数，每个里面都这么判断，相当相当的烦。怎么办？我们来面向对象一下。

现在开始按照动物拆分，100个天使，每个天使创造一种动物。创造哪种动物，就站在哪种动物的角度考虑问题，我吃的时候怎么吃，跑的时候怎么跑，都跟别人无关，这么一来，每个人就专注多了。每个动物只关注我要怎么才能活着，不必站在上帝的角度考虑问题。这个过程，是类的划分过程，也就是封装的过程。

这时候，上帝觉得自然界光有动物是不行的，还要有植物，刚才说的这些都是动物，植物的特点跟动物有很大区别。假设你是上帝，为每种生物安排衣食住行，那是相当复杂的。偷懒吧，上帝说，植物们，你们自己生长吧，动物们，你们吃喝玩乐吧，假如能达到这个效果，那很省事。

上帝用一个循环来遍历所有动物，让他们吃喝玩乐，用另外一个循环让植物欣欣向荣。动物跟植物为什么要区别对待？因为它们不是同样的东西，能做的事情不同。所有动物派生于动物这个基础类型，从动物这个种类下，又分出各种纲，各种目，各种属。狮子是哺乳动物，猴子也是，但是狮子是猫科动物，猴子是灵长动物，这就构成了一个倒着的树状体系，一层一层形成继承关系。哺乳动物会喂奶，那么所有继承自哺乳动物的，都自动拥有这个特征。整个这一切，构成了继承链。

假设有一天由于变异出现了新物种，不必劳烦上帝关照，只要鉴别一下它属于什么类型，就知道能做什么事了，它的一举一动，都必然拥有它所继承的种类的特征。

这样就能描述生物界了吗？不，还有那么一些怪胎的存在。你认为哺乳动物都不会飞，那就错了，因为蝙蝠会飞。蝙蝠会飞是它自身的特性，并非继承自哺乳动物，但是“飞”这个动作，却非蝙蝠独有。如果把“飞”定义成接口，那就很美好了，蝙蝠实现了它的飞行接口，虽然内部实现跟鸟类有所不同，而且这并不影响它的哺乳动物特性。

总之，是否面向对象只是思维方式的不同。做一个软件，面向对象也能做，不面向对象也能做。我的观点，如果关注可维护性和协作性，从目前的角度，面向对象是很好的选择，它很自然，很优雅，优雅得只要打一个“.”，你就能想起来什么事能做，什么事不能做。

2.2. 模块的职责划分

面向对象的一个基本原则是分而治之（Divide and Conquer），这种方法论提倡将程序模块化，各模块实现单独的功能，在统一的管理下协同工作，构成整个系统。

在具体实施的时候，又有两种倾向：将功能高度集中于主控制模块；将功能下放到各部件。这两种做法都有很高的可行性，也分别有大量支持者。我觉得在一些程度上，后者更贴近人类的思维方式，更适合用人性化的观念来解释。

将两种类型的程序对应到生物集群，第一种相当于一个蚁群，第二个相当于人群。蚁群的特点是，个体能够完成的事务非常有限，但是因为在一个非常强有力的统治者蚁后的控制下，它们能够协同工作，统一调度，完成不可想象的事件。人群的特点是，每个人都可以独立思考，能够理解别人的指令，并且根据这些指令做到力所能及的事情。作为人群的统治者，他的智慧不需要比其他人的高太多，只需要从宏观上来把握一些事情即可。

从系统的实现来说，第一种方式难度很高。完成单个蚂蚁（小模块）的功能并不复杂，创建大量的蚂蚁也只不过是需要的时间多一点，但是，当开始设计蚁后（总控模块）的时候，噩梦开始了，整个调度算法实在是一件令人头疼的事情。对于比较复杂一点的系统，让一个人去设计这个模块简直是不可思议，但是如果由多个人共同完成这个模块，又面临着互相理解的问题，每个人的思路都不相同，在努力协作的过程中，大量的时间被浪费在交流和意见的统一上。与此同时，制作蚂蚁的程序员日益烦躁，觉得自己的工作没有难度，无聊，士气低下……

换一种思路，从人类管理的角度来看问题。假设有一支庞大的军队（假设是一个集团军），司令官需要他的士兵列队，我们来为这个系统设计调度算法。先假设所有士兵跟蚂蚁一样笨，他们只能明白“站到司令部大门往东50米，往北100米的地方”这样的简单指令，请同情一下这位司令官，他不得不为每个士兵来指定一个位置，并且不得不研究列队的规则，他需要整天忙碌来完成这样一个庞大的任务（而且还不一定能完成）。他叹息道：哦，上帝……

让我们设法来减轻他的烦恼吧，目标是让每个人都主动参与这个事件，不再那么被动，大家都努力完成自己力所能及的工作。于是我们授权各级指挥官让他自己的士兵列队，这样一来，司令官的工作简单多了，他发布命令：各位军长请注意，我命令你们列队，按照番号顺序，分布到司令部门口的空地上（假设这个空地足够大，姑且认为能够容纳整个集团军），各军之间保持50米间隔。

接到命令以后，军长们开始忙碌，而司令官先生已经可以搬一把椅子坐到电话机旁，等待列队完毕的报告了。同样，军长要做的事情，也就是告诉属下的各位师长，让他们按照番号顺序列队，就这样，命令被传递到最下面一级。班长大喊：伙计们，按照个头排成一列，矮的在前面，高的在后面，前后间隔一米！于是，所有人站到了他应该站的位置，望着在短时间内迅速列队的整个集团军，司令官太满意了。

我们发现了什么？很显然，下放权力的方式要省事得多，更关键的是，它使得每个人都做一定的事情，但是又不成为负担。在设计者思路清晰化的同时，负责为系统每个部分编写代码的人员也更容易享受到编程的乐趣，就算是最低层的程序员也有了发挥自己才能、用自己的思路去影响系统的机会，而且，系统集成的过程将变得更加简单。

对于一名软件设计师来说，他的思想决定了他所设计出来的软件结构，将自己的灵魂注入到冰冷的代码中，这是一种艺术。然而，不同的人有不同的风格，设计者对于世界的认知方式不同，他们对于同样的需求，可能采用的设计方式也多种多样。

3. 怎么设计我们的象棋程序

3.1. 为象棋程序划分模块

做一个象棋程序，有哪些事情要做呢？

首先，我们要能够初始化一个棋局，把棋盘和棋子绘制出来，点击棋子的时候，能给出它可以走的地方，可以移动这个棋子，也可以吃掉对方的棋子。走完一步，要能够判断是否将军，如果吃掉了对方的将帅，能够判断棋局的终止。这些东西，除了绘图之外，我们都放在棋局模块里，我们有个第一个模块Game。绘图模块的职责比较单一，我们把它放在一个棋盘模块中，这是第二个模块ChessBoard。

天下之事，事事都是棋局，人在局中为名来，为利往，都是棋子。可见，与棋局相对的就是棋子了。按照我们在第二部分提到的思路，棋子应当是要承担一些职责的，那么，哪些事情适合交给棋子来做呢？

我们定义这么一个规则：做一件事，如果有多个参与者，其中某个参与者要付出的代价最大，这一步就由这个参与者来负责做。

我们把走棋的这个过程分解，这里有四个部分：

• 判断我有没有可能出现在那个位置，比如说，象不能过河，老将和卫士不能出九宫格。
• 判断目标位置有没有己方棋子，如果有，也过不去。
• 判断能否直接到达目标位置，比如说，马腿是否被挡着了？象眼是否被塞着了？
• 移动过去，如果有对方棋子，吃掉它。

从第一步来看，这个过程不依赖于其他任何东西，每个棋子都应当能够牢记自己能去什么地方，不能去什么地方，只要你给它一个棋盘坐标，它自己是可以知道能不能去的。比如象知道自己不能过河，如果你给的坐标就超过了，它可以知道自己不能去。所以，这个职责我们放给棋子。

再看第二步，这个我们怎么判断呢？假设我们是一个士兵，在平原上打仗，我想知道前面山顶有没有人，怎么办？看了很多电影的我们表示，很好办。“总部总部，请侦察对面山顶。”所以，这个过程我们可以看到，检索目标位置不是棋子自身的职责，他只是调用了某个别的东西（己方司令部），得到了结果。

下面是第三步，这里面有可能不需要依赖于其他模块，也可能要依赖，怎么解释呢？比如说卫士，他走路只看距离，如果是他的合法可达位置，并且和当前位置距离的平方为1+1=2，那就可以直接过去，不需要依赖任何外部模块。但是如果是马，要先看距离的平方是不是1+4=5，然后再找马腿的位置，再去看那个位置有没有棋子。所以这种情况下，就要依赖外部模块。

第四步看似很简单，过去的时候发个通知给司令部，我换地方了！但司令部那边要把当前所有人分别在哪都记录着，所以他要做的事情其实比棋子更复杂，所以这一步可以让他做。

于是，我们得出结论，棋子的职责应该是这些：

• 判断自己是否可能出现在某位置
• 判断自己能否到达某位置

现在我们就有了Chess模块，并且从它派生出各种棋子，同时，为这些棋子实现一个工厂模块ChessFactory，用于根据参数创建这些棋子。

现在我们来考虑，谁来提供这个查询的服务，承担司令部的这些职责，棋子的位置都保存在棋局中了，所以，很自然地，棋局承担了这个职责。使用。

简单地考虑一下，我们的棋局应当能够：

• 初始化。初始化方法做的是把棋局恢复成初始状态，每次重新开局之前，我们可以这么做一下。
• 走棋。走棋是把给出的棋子移动到指定位置，如果目标位置没有别的棋子，只做移动，否则还要把对方杀死。走棋之前有一些判断条件，我们也把它们列出来。
• 列出某棋子的可达范围。这其实是一个辅助功能，当用户点击某棋子的时候，界面上能够标示出所有该棋子的可到达位置，便于用户选择，当用户选择其中某一个的时候，把棋子移动过去。
• 判断是否终局。每一步棋走完，我们都需要看一下是否有一方获胜，如果有，本局应当终止。

3.2. 代码结构

根据上述的结论，我们建立了这么4个代码文件，用于存放不同的模块：

• game，存放棋局相关的功能
• chessboard，存放绘制棋盘和棋子相关的功能，点击操作也由它负责传递
• config，存放各种配置信息，比如棋盘大小等等
• chessman，存放各种棋子的功能和棋子生成器

注意到我在chessman.js里面，定义了多个模块，这其实就是我这个thin框架的核心理念，模块跟文件不一一对应，模块对应于Java中的class文件，而js文件对应于Java中的jar文件，是模块的集合。这么做当然也有弊端，因为无法得知模块是否有冲突，或者存在被覆盖的情况，引用也不是很方面，所以我为此还建立了一套管理和发布机制，专门用来解决这个问题。在小型项目纯手写代码的情况下，直接这样用就可以了。代码细节不一一列出，请读者自行查看。

4. 可能的改进

上面我们实现了一个可以在单机下双人对战的象棋程序，运行得还不错，但是我们想要给它一些增强，应当如何去做呢？

如果我们想要本机开多个棋局，怎么办？

在我们现有结构下，其实很简单，因为我们模块化做得还是挺好的，Game可以作为顶层模型，然后创建出对应的DOM容器，用我们上次写的Bind来扫描一遍，自动创建实例，就可以了。

另外一个很典型的增强是，既然我们都做了单机的对战了，是不是可以搞一个服务端，变成联机的对战呢？当然可以，要做这个，我们需要改动的代码是Game模块，这一步不再适合直接创建了，而是要放在新建棋局的服务端回调里面，棋局的状态也需要在服务端保存一份，然后每次下棋，把走的棋子和坐标放过去，对其他任何模块都没有改动。从这里我们也可以看到如果代码进行了合理的分层，当需要改进的时候，对原代码改动有多么容易。

再有这么一天，我们还要做棋局的撤销怎么办？虽然这个很不好，有损大丈夫的威名，但我们只从实现角度来分析一下。在设计模式中，有一种叫做命令模式，这种模式其实就很适合做undo跟redo，只要把每个事情都封装为步骤，那么，这两种操作就变成了正向和反向的两种步骤了，做起来也就非常容易。

还不满意，要添加人工智能怎么办？抛开人工智能常用的剪枝算法不谈，我们假设已有这么个算法，只需要在一方移动棋子之后，把当前局势传递给这个算法得到下一步即可。

综上所述，做大一点的Web应用，必须先做模块化，把模块按照功能划分，理清它们之间的关系，然后再用合适的框架去管理维护。作者正在编写的thin框架就是试图从模块入手，一步一步添加其他功能，把它做成一个有一定可用性的框架。

本文的Demo地址是：http://xufei.github.io/thin/demo/chess.html