马尔可夫链——从一个编程作业中看看程序设计的一些细节问题

马尔可夫链（Markov Chain），这是我们《程序设计方法学》课程的一个小小的作业，这个作业，主要目的并不是实现算法，而是“如何”实现算法，以及从代码中看出每个人程序设计的“风格”。 因为即使是很少的代码也能暴露出一个编程者的功底和风格。
我觉得这是个很有意思的话题，所以也在这里把我的部分代码发出来，并加以说明以作抛砖引玉。

目标

先稍稍介绍下马尔可夫链，简单地说就是输入一篇文章（其实是单词序列），建立前缀表后缀表，然后根据前缀随机选择后缀，如此迭代，生成一篇“看起来像文章 的随机文本”。当然这只是马尔可夫链的一个应用，不过也算挺典型的。我曾经在开发一些应用的时候用类似的程序来生成测试数据。 

程序结构

根据我们老师的要求，程序从文件读入样本数据，从标准输出打印生成的文本，其他没有具体要求。
我选择C#来实现这一程序。
我的程序流程非常简单：
读取样本 -> 建立前缀、后缀表 -> 生成 -> 输出

数据结构

根据编程经验和《程序设计实践》，前缀表采用哈希表，后缀表采用链表。
后缀表非常简单，每一个后缀都有一个Next，也就是说后缀本身就是一个链表节点，也就不需要LinkedList<Suffix>来帮忙了。

class Suffix {
    public string Word { get; set; }
    public Suffix Next { get; set; }
}

相比之下，前缀就稍微麻烦一点了。首先“前缀”是一个单词序列，存储上不管用数组还是.NET FCL中的各种集合都没问题，但是这二者都无法方便地哈希。所以我采取了一个投机取巧的方法，就是把前缀拼接成一个字符串，用string做哈希表的Key。
由于前缀涉及到一些具体操作，我把它单独提出来写成Prefix，而以整合了Prefix与Suffix的State来做迭代中的算子，所以我的前缀表就是Dictionary<string, State>，这个前缀表的设计，显然有点寒碜，而后缀表就是由Suffix构成的链表。 

class Prefix {
    #region Properties

    /// <summary>
    /// 前缀数
    /// </summary>
    public static int PrefixCount = 2;

    /// <summary>
    /// 前缀词
    /// </summary>
    public string[] PrefixWords { get; set; }

    #endregion

    #region Public Methods

    /// <summary>
    /// 构造一个空的Prefix
    /// </summary>
    /// <returns></returns>
    public static Prefix CreateEmpty() {
        return new Prefix();
    }

    /// <summary>
    /// 滚动一下
    /// </summary>
    public Prefix Roll(string suf) {
        if (PrefixCount == 1) {
            PrefixWords[0] = suf;
        } else {
            Array.Copy(PrefixWords, 1, PrefixWords, 0, PrefixCount - 1);
            PrefixWords[PrefixCount - 1] = suf;
        }
        return this;
    }

    /// <summary>
    /// 克隆一个完全一样的Prefix对象
    /// </summary>
    public Prefix Clone() {
        return new Prefix(PrefixWords);
    }

    #endregion

    #region Constructors

    private Prefix() {
        PrefixWords = new string[PrefixCount];
    }

    /// <summary>
    /// 根据已知单词构造一个Prefix
    /// </summary>
    /// <param name="words">前缀单词序列</param>
    public Prefix(params string[] words) {
        if (words.Length != PrefixCount) {
            throw new ArgumentException("Prefix count error!", "words");
        }
        PrefixWords = new string[PrefixCount];
        Array.Copy(words, PrefixWords, PrefixCount);
    }

    #endregion
}

重写GetHashCode()的代码我就省略了。

细节

不论是建立词缀表还是生成文本的过程中，只要选择了一个后缀，前缀就需要滚动一次，所以我这里做了一种“古怪”的设计。首先是在迭代过程中，Prefix 对象始终是同一个对象的引用，只是它内部维护的数组在滚动，这个应该很好理解。但是这样会出现一个问题，那就是State对Pref的引用会出现混乱。所 以我只好给Pref设计了一个Clone方法，而事后回想，这是一个完全错误的设计，因为我可以用另外的方法来避免这种窘境（下文会说到）。
在生成中，涉及到一个怎么设计返回值的问题，关于这个问题我考虑了不少，也改了几次。
最直接的办法：直接向命令行输出，因为题目要求最终输出到命令行，所以这个方法的确是可行的，但是我考虑到这些代码的重用性，没采取这种方法。
厚道点的办法：不像命令行输出，而是传入一个TextWriter，虽然这个方法和上一种比，完全是换汤不换药，但是好歹也是考虑的多了一点点。

上面两种方法都有一个问题，就是我们在设计函数的时候，给一个函数多大的权限呢？我们常认为：要么就输入输出都自己处理，要么就都不处理，把输入输出交给别的函数专职处理。上面两种方法无疑违背了这一个规律，因为TextGenerator类的构造函数参数是IEnumerable<string>，也就是说，输入是不由TextGenerator处理的，而这里却又自作主张地处理了输出，显然让人晕乎乎。

最简单的办法：直接返回一个生成的字符串，我想这会是大多数人的方案。但是也有明显的缺陷：对于英文，很自然地我们会在每个单词后面加上一个空格，但是如果处理的是中文呢？加上个空格显然很郁闷。也就是说这样设计就完全没有给用户（函数的调用者，下同）选择格式的机会。难免有自作聪明之嫌。虽然我最后的程序中保留了这段代码，但也是觉得聊胜于无了。
较自由的办法：调用的时候，传入一个Action<string>，也就是一个委托，决定每一个被选中的单词做怎么操作，在这个例子中，也就是

s => {
    Console.Write(s);
    Console.Write(" ");
}

这样做看起来已经不错了，还挺现代的写法，不过我最终还是没有选择这样的方法，因为我采取了——

我最终的办法：返回IEnumerable<string>，这里可以发挥C#强大的语言特性，使用yield来返回，这样用户可以直接

foreach (string s in gen.Generate(maxWordCount)) {
    Console.Write(s);
    Console.Write(" ");
}

这个也算一个迭代器模式的小小的运用吧。其实这个方法和传递委托的方法相差已经很小了，但是我个人喜欢后者。

遗憾

这就不得不说文中提到的那个我最大的错误了。
首先就是我从数据的定义上就出现了问题，因为State里保留的Prefix引用根本没有发挥作用，而Suffix也只是一个头指针，也就是说与其如此复杂还弄出个Prefix.Clone()，还不如直接就把State的小命给革掉。Prefix直接就能映射到Suffix，也省的一个State在中间耽搁着。而Prefix采用了一种“猥琐”的哈希方式，也是有待改进。

小结

虽然是一个小程序（据说perl只用19行），基本算法也相当简单，但是从中暴露的程序设计的问题却不少，接口职责的设计毫无疑问是程序设计当中的重要部分，“高内聚低耦合”几个字天天挂在嘴皮边上，但真正干活的时候也不是那么容易实现的。身为程序员，难道不应该在这些方面多动动脑筋吗？

扩展

在这个程序中，我完全没有考虑API设计中的另一重要环节——异常。并不是疏忽，而是我从一开始就没有把这个列入考虑范围，所以这也是一个可扩展的地方。什么地方抛出异常，抛出什么异常，怎么接到异常，怎么处理，都值得设计。

附全部程序的源代码下载（敲打我）