javascript设计模式交流(2)

核心提示： 附：八皇后问题八皇后问题是一个古老而著名的问题，是回溯算法的典型例题，javascript设计模式交流(2)(2)，该问题是十九世纪著名的数学家高斯1850年提出：在8X8格的国际象棋上摆放八个皇后，使其不能互相攻击，解释器是非常适合的模式，此外解释器还有一个不太为人所注意的优势，即任意两

附：八皇后问题

八皇后问题是一个古老而著名的问题，是回溯算法的典型例题。该问题是十九世纪著名的数学家高斯1850年提出：在8X8格的国际象棋上摆放八个皇后，使其不能互相攻击，即任意两个皇后都不能处于同一行、同一列或同一斜线上，问有多少种摆法。

高斯认为有76种方案。1854年在柏林的象棋杂志上不同的作者发表了40种不同的解，后来有人用图论的方法解出92种结果。

解释器模式听起来高高在上，但它其实应用广泛而且非常实用，javascript是一门解释型语言，它的大多数引擎（Actionscript是一个特例）都是解释器，解释器的实现十分复杂，然而解释器模式并非如此 ，思想上解释器模式借鉴了解释器的实现，但根据需要，也可以用很简单的代码实现。

在GOF book中这样解释它的意图：给定一个语言，定义它文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。

这听起来十分复杂，但是事实是，语言可以自由设定，所以它的实现可能非常简单。举个例子，假如我用wsad来代表上下左右，那么一个wasd组成的字符串即可表示一条二维空间内的路径，它的每个"句子"即是一个字母，那么实现一个根据wasd序列来显示相应路线的解释器并不困难。更进一步，可以把一个解释器看作是由字符流作为参数的复杂函数，它的复杂程度取决于字符流的格式。

解释器模式执行速度通常不快（大多数时候非常慢），而且错误调试比较困难（附注：虽然调试比较困难，但事实上它降低了错误的发生可能性），但它的优势是显而易见的，它能有效控制模块之间接口的复杂性，对于那种执行频率不高但代码频率足够高，且多样性很强的功能，解释器是非常适合的模式。此外解释器还有一个不太为人所注意的优势，就是它可以方便地跨语言和跨平台。