数独求解——面向对象解决算法问题（二）

       昨天发了一篇:《数独求解——面向对象解决算法问题》，估计有很多人想拍砖了吧，呵呵，我先顶住，接着上上第二篇，在此篇中，主要回答以下几个问题：

1.这样面向对象的写法有什么好处？有什么缺点呢？

       有很多人都说这题不应该用面向对象的做法做。因为首先，我的算法中借助了过多的语言特性，如泛型，如栈和队列，如类。而这些东西对解决此题提供了极大的帮助，不利于提升自己的算法能力，也违背了出题人的初衷。OK，我致歉。但我必须反驳：

• 因为你可以发现，此题如果用面向结构的方式做，我相信不出三百行代码，一定可以求解。虽然不能说代码多就表示难写，但我只想证明，我不是为了偷懒而故意回避面向过程。面向对象解算法问题往往需要花更多的代价。
• 那么为何你还用面向对象呢？因为我最近一直在看《大话设计模式》，感觉想借助之试一下自己的抽象能力。

       既然面向对象添加了工作量，并且并没有减轻工作难度，那它带来了什么好处呢？

• 代码的可读性。我必须忏悔，我的代码不具备此特性。
• 代码的可移植性。你可以方便的将此代码移植到webform、silverlight上，已经抽象出来的三个类，不需要进行任何修改。
• 扩展性。你可以非常方便地改变棋盘的维数、初始化样式。同时，这里抽象出来的三个类，还容易实现其他的操作，比如，你想找出这个问题的所有解，只需要改前台的递归算法就可以了，其他的不用改。如果你想增加一些功能。

2.这个系统中存在的巨多问题，不知道你发现没？

        首先，没有很好地做到遵循面向对象的开闭原则（对扩展开发，对修改封闭），因为我对修改也开发了，前台可以随便地修改这三类中本不该公开的属性，如version属性，这个不应该让前台用户进行修改，再如ChooseValues这个数组，前台应该只有读取的功能。再如Grid的GridRow属性，为了对外不公开，我将它设计为internal set，但更好的做法应该是设计为只读，通过构造函数或其他方式为其赋值。

       另外系统中提供了过多的操作，而这些操作是我们不必要的，如：Grid类继承自IComparable实现了CompareTo(object obj)方法，但这个方法我一直没有用到。其他的这样的还挺多。

       上面讲的是过渡封装，但系统中还存在封装不够的问题。如：返回一个单元格可选的数字，这个方法应该放到GridRowCollection中。

        其他问题。。。。。。。。

3.这个题中，我用的是栈来缓存可能要回溯的Grid对象，实际上也可以考虑用队列来做，不过经过我思考和测试，此题更适合用栈。

4.这是一个算法题，就要求有较高的算法精度和较低的时间复杂度，很显然，这方面没有过好，过多的循环，必然会损失过多的性能。编程上的偷懒，带来了程序的稀乱。

 

      这个题的算法绝不是维一的，希望大家也发表一下自己的意见，另外，我不介意有人再次拍砖，放到首页，就是希望有人来拍砖。请不必吝啬，希望得到大家的建议。