我們把那個底盤稱為board，該board類實乙個容器，是乙個6*6(n*n)的棋盤。對於該棋盤，我們抽象的看，那是不是乙個**呢？
所以我設想，這個board類從我們的table類繼承，該board類負責對底盤中的所有容器的控制。
board類應該封裝乙個6*6(n*n)的棋盤的事實（細節），然後應該提供乙個adddevice(obj,x,y)的方法，x和y很顯然，就是裝置要放置的位置，這個obj就是允許放置的裝置。
我們所需要的裝置有
光線源頭(line_head)
水晶(crystal)
傳光器(line_transmission)
阻礙物(obstacle)
炸彈(bomb)
時間漏斗(time_funnel)
變色器(colour_changing)
選取框(choice_box)
如果，我建立乙個devicebase類作為這些裝置的基類，估計也沒有什麼不妥，不過這些裝置之間有的相同點實在是不多，因此要建立devicebase類似乎意思不大。我又考慮這些裝置應該有的共同點是：
draw，在給定的x和y的範圍內繪製自己的形狀和外觀
getfocus，當得到焦點的時候，要在當前裝置框的周圍繪製出手柄標記
lostfocus，當失去焦點的時候，要在當前裝置框的周圍撤銷手柄標記
所以我打算宣告乙個介面idevice，該介面宣告了以上的方法。
因此board類的adddevice為：idevice,x,y這樣會比較好點，感覺。
然後，我要新增乙個新的裝置：空白（blank），6*6的**預設存放的都是空白，該blank當然也實現idevice介面。
接下來，我們要考慮光，光是不是物件呢？那一定是的。我們需要乙個light類。從遊戲的直觀角度來講，line_head需要乙個send方法，其他的裝置需要乙個receive方法。
具有receive方法的裝置體現多型，每個裝置有自己對光的處理模式：延伸，阻隔和**等。延伸其實就是繼續對光線的繪製。所以，我們在設計的時候，如果考慮對光的繪製是由裝置來控制的，我感覺就錯了。
我的設計是：光由自己繪製，但繪製的控制權由board負責，裝置向board描述光的方向性。
比如：line_head向board發出訊息要求從x,y開始沿什麼方向繪製什麼顏色light
board沿方向計算table中沿途的第乙個裝置，然後將控制權給light繪製。
light繪製完畢後，board通知第乙個遇到的裝置接受光線
該裝置依據自身的規則計算光線的延伸，併發訊息給board，board再計算。
如果board計算出的第乙個裝置是bomb，則遊戲結束
有些裝置允許旋轉和移動
因此我們要再宣告
irotate介面
toclockwise 順時針
tocounterclockwise 逆時針
imove介面
toup
todown
toleft
toright
我們希望當裝置得到焦點的時候，繪製出的控制代碼可以有明顯的提示讓使用者該裝置是不是可以旋轉或移動，或都不行。
(所有用具的移動和旋轉都需要靠選取框來完成~~選取框移動到沒有用具的格仔或該用具不可移動和旋轉的時候~選取框表示成狀態1~~當移動到可移動和旋轉的用具時候~選取框表示成狀態2~~玩家第一次確認後，就可移動該用具，選取框表示成狀態3~玩家第二次確認後，就可旋轉該用具，選取框表示成狀態4~~玩家第三次確認後，完成對該用具的操作，選取框表示成狀態2~~當選取框處於狀態1和狀態2的時候~可以上下左右的移動~來捕捉用具~~在狀態3下，移動用具即移動選取框，選取框的狀態應同時帶進新的cell中~~)
選中了以後~先是移動~再是旋轉~~
我考慮底盤的每個單元格都應該是乙個物件，我們把它宣告為cell物件，該物件是乙個容器物件，當board初始化的時候，每乙個cell都存放的是blank物件，當board使用adddevice方法放入裝置時，其實是將裝置放入cell中。
為什麼我要這樣做呢？我這樣考慮的，依據mvc，檢視（玩家直接觀察的部分）的變化其實是對資料（board）的操作呈現。board提供所有對遊戲行為的支援，只不過這些行為分為兩種
一種是：board的直接行為，比如提供使用者對cell選擇確定等控制
一種是：對裝置的控制，這些行為其實是包裝了裝置的行為。
所以，底盤（board）需要乙個currentcell屬性，描述當前具有焦點的單元格。底盤實現上下左右的方法（imove介面），這些方法影響currentcell屬性。currentcell總是返回當前board有焦點的那個cell。
當board執行imove介面的方法時，會激發單元格焦點改變的事件，該事件會通知單元格中的裝置改變繪製手柄（就是那個選取框）。得到焦點的時候繪製手柄，失去焦點的時候消除手柄。
繪製選取框是乙個很值得考慮的問題，從效果來說，我們希望每個裝置的選取框都不一樣，感覺好看點，還有裝置的可旋轉和可移動也希望選取框有不同的繪製效果，但是也有可能大部分裝置的選取框繪製效果一樣，如果你認為要寫乙個devicebase來實現選取框的繪製也可以，不過我提供另外的思路。
cell來實現預設的焦點得失時的選取框的繪製。
首先裝置要實現can系列屬性，向它所在的單元格描述當前裝置是否可以旋轉或者移動等。這個我們可以在idevice介面中宣告canrotate，canmove，當cell得到焦點的時候，它根據它所容納的裝置的can系列來繪製選取框。如果裝置提供了自己的選取框，那cell將用裝置的繪製方法替換cell的預設，這種方式是我從asp.net學來的。這種設計模式，要比繼承更靈活有意思。
初始的設計思路
我們把那個底盤稱為board，該board類實乙個容器，是乙個6 6 n n 的棋盤。對於該棋盤，我們抽象的看，那是不是乙個 呢？所以我設想，這個board類從我們的table類繼承，該board類負責對底盤中的所有容器的控制。board類應該封裝乙個6 6 n n 的棋盤的事實 細節 然後應該提供...
Restful API的設計思路
api的就是程式設計師的ui，和其他ui一樣，你必須仔細考慮它的使用者體驗！restful只是web api json傳輸介面通過http調，取到還要自己解。rpc一般都是配套的，客戶端直接像調本地函式一樣呼叫 一般用在內網服務間呼叫，可以用rpc的框架thrift swagger可以用來管理你的r...
barrel shifer的設計思路
設計電路時，經常會遇到從乙個大位寬資料m中選擇連續的資料n，此時對每bit都使用mx顯然浪費了資源，而barrel shifter是一種不錯的選擇。設計思路 以example2為例 step1 根據輸入輸出資料位寬確定最大移位值，7 2 5bit。step2 將最大移位值依次減去1 2 4 2 n ...