Tennis Kata的状态机实现,还有一些问题

[yesterdaysun]

抛砖引玉: https://github.com/yesterdaysun/Kata

起因是看书看到自动状态机的东西, 然后想到之前Joseph和梁辰实现的一个基于状态机的Tennis, 于是就自己实现了一个Ruby的.
因为想要保持自动机逻辑的简单性,也就实现的比较蠢了,把所有可能的状态全部列下来(其实也就36种).

问题就是接下来这个实现还能进一步简化吗, 因为感觉下面就势必要把一些类似的状态(比如15 30之类的比分)合并, 但是这样一来就要给自动机/状态添加复杂性, 可能会失去这种实现的目的(简单性).
我在想有没有好的思路,能够只增加一点点复杂性,但是能让程序更加简约?

大家怎么想的呢?

[Terry]

我觉得你的解法很有意思，引发了我两个方面的思考：

1. 单元测试测数据么？

2. 状态机是否更不容易重构？

--
您收到此邮件是因为您订阅了Google网上论坛上的“agileshanghai”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到agileshangha...@googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

[Joseph Yao]

@Eric,

看了你的代码，让我学习了一把用状态机类库来解决问题的思路，谢谢。你问能否进一步简化状态机，我不知道怎么做。我之前的实现（可以参考 https://github.com/JosephYao/Tennis_Inspired_by_LiangCheng）中的 Tennis 类有个 nextMatchStateAfterDifferentScore 方法，我也感觉复杂了一点，但是实在没想到什么办法简化，也只能作罢。而你的状态机里面倒是没有什么复杂的地方，不过我觉得重复的数据多了一点，比如下面的代码。如果让我选择的话，我还是喜欢我那个版本，重复少一点。:)

['0 0','1', '15 0’], ['15 0','1', '30 0'],
['0 0','2', '0 15’], ['15 0','2', '15 15’]

@Terry，你问了两个关键的问题，引发了我的思考。:)

1. 单元测试测数据么？

    我觉得单元测试需要测这种以数据为主的状态机代码，因为数据是实现的一部分。虽然不用测每种可能的数据，但是也不能因为代码实现是数据驱动的（比如状态机）就不做单元测试了。我觉得 Eric 的测试少了一点，比如 ['11', '15 15’] 这种情况。

2. 状态机是否更不容易重构？
    

    我感觉下面的状态机要重构的确可能难一些。虽然重复数据明显，但是由于主要实现都是数据，如果要加入新的代码来去掉重复，就很可能改变状态机的结构，比如引入一些函数。不过，我要试一下才能确定。

谢谢，

Joseph

[武可]

1. 单元测试测数据么？

我感觉一个东西是数据还是程序，其实取决于我们的视角。

举个极端的例子，比如这个状态机的需求不断扩大，对它的表达能力要求越来越高，最终发现直接用JS之类的脚本来描述才能满足需求。那么原本的主程序，就成了JS解释器。而关于网球逻辑的部分都在脚本中。

就像《黑客与画家》的作者说的，任何C程序复杂到一定程度，都会包含一个部分功能的lisp实现。

这时候，对于解释器的单元测试，可以用来验证解释器的正确性。如果你认为这个程序的任务是提供一个解释器，那么就不需要测试描述网球规则的脚本。

反之，如果任务程序的目的是正确给出网球比分，那么可能就要写针对脚本的测试。

2. 状态机是否更不容易重构？

我认为状态机就是一种语言，要对它重构可能需要特殊的技巧。就像刚刚接触一种与已知范式差别较大的程序语言，可能也不容易掌握怎么重构。

[Terry]

谢谢武可和Joseph对我两个问题的回复。两位讲得都很有道理。

我从前在通信行业时常用状态机。状态机把解决方案碎片化，很不好单元测试。或者测了效果也有限。常常还有测来测去都不知道测的是产品代码还是测试代码的现象。而且写了好多年状态机的后遗症是看什么都是状态机。记得刚离开Nokia的时候不论写什么都往状态机上靠。后来看到一些好的状态机的例子往往有元编程的味道，我现在自己也开始把状态机向这个方向重构。

[武可]

往往对一门技术了解的越深入，看到它的局限性越多。

不知道有没有什么特别适合状态机的场景，可以给像我这样不太熟悉状态机的人科普一下心得？

前一段时间看到有个相关的课程，因为不知道自己能不能保证时间投入，没有学习，好像有点可惜了。

https://www.coursera.org/course/automata