昨天發了一篇:《數獨求解——物件導向解決演算法問題》，估計有很多人想拍磚了吧，呵呵，我先頂住，接著上上第二篇，在此篇中，主要回答以下幾個問題：
1.這樣物件導向的寫法有什麼好處？有什麼缺點呢？
有很多人都說這題不應該用物件導向的做法做。因為首先，我的演算法中借助了過多的語言特性，如汎型，如棧和佇列，如類。而這些東西對解決此題提供了極大的幫助，不利於提公升自己的演算法能力，也違背了出題人的初衷。ok，我致歉。但我必須反駁：
既然物件導向新增了工作量，並且並沒有減輕工作難度，那它帶來了什麼好處呢？
2.這個系統中存在的巨多問題，不知道你發現沒？
首先，沒有很好地做到遵循物件導向的開閉原則（對擴充套件開發，對修改封閉），因為我對修改也開發了，前台可以隨便地修改這三類中本不該公開的屬性，如version屬性，這個不應該讓前台使用者進行修改，再如choosevalues這個陣列，前台應該只有讀取的功能。再如grid的gridrow屬性，為了對外不公開，我將它設計為internal set，但更好的做法應該是設計為唯讀，通過建構函式或其他方式為其賦值。
另外系統中提供了過多的操作，而這些操作是我們不必要的，如：grid類繼承自icomparable實現了compareto(object obj)方法，但這個方法我一直沒有用到。其他的這樣的還挺多。
上面講的是過渡封裝，但系統中還存在封裝不夠的問題。如：返回乙個單元格可選的數字，這個方法應該放到gridrowcollection中。
其他問題。。。。。。。。
3.這個題中，我用的是棧來快取可能要回溯的grid物件，實際上也可以考慮用佇列來做，不過經過我思考和測試，此題更適合用棧。
4.這是乙個演算法題，就要求有較高的演算法精度和較低的時間複雜度，很顯然，這方面沒有過好，過多的迴圈，必然會損失過多的效能。程式設計上的偷懶，帶來了程式的稀亂。
這個題的演算法絕不是維一的，希望大家也發表一下自己的意見，另外，我不介意有人再次拍磚，放到首頁，就是希望有人來拍磚。請不必吝嗇，希望得到大家的建議。
數獨求解 物件導向解決演算法問題（一）
最近遇到乙個演算法題，名字叫做數獨求解，問題描述如下 在9 9的方陣中，包含了81個小格仔 九行九列 其中又再分成九個小正方形 稱為宮 每宮有九小格。遊戲剛開始時，盤面上有些小格已經填了數字 稱為初盤 遊戲者要在空白的小格中填入1到9的數字，使得最後每行 每列 每宮中都包含1到9，但不允許出現重複的...
分治思想解決演算法問題
不多bb，o n 2 include using namespace std void solve int f 5000 int m cin m for int i 0 i m i cin a i f 0 0 for int i 1 i m i f i f i 1 sum cout f m 1 en...
0 1揹包問題之動態規劃解決演算法 二
include includeint m 6 5 8 m i j k 表示揹包容量為j,揹包體積為k,可選物品為i,i 1,i 2.n時揹包問題的最優解 int getmin int x,int y int getmax int x,int y void traceback int w,int b ...