第十四周總結前些天一直被許可權區分的三種操作員的問題困擾，也說不上是困擾，就是我的方向出現了偏差。
當初想的是按照介面實現三種不同許可權操作員的眾多功能，把選單中的各項分許可權劃歸為不同許可權介面中的虛方法，當初想的是為基於開閉原則來設計這些介面實現系統的，可是總是感覺有問題，就去找學宇請教。經過**，最終學宇給了比較高的評價，大加讚賞一番，的確這種介面之間的組合也能很好的適應以後增加其他許可權使用者的變化，按照基本需求這些介面之間不同的組合就能出現不同的功能介面，可以用來增加不同許可權使用者。(先這麼說著，後面就出問題了。)
上週聽學宇他們幾個人介紹了好多他們的系統初步設計，後來也看過學宇的系統包圖，總體上來看她的畫的系統包圖，亂亂的感覺。各個層之間的關係貌似表述的比較清楚。可我的系統分層還沒有定論，聽著學宇天花亂墜的介紹自己的分層，從她嘴裡說出來的分層總也是那麼簡潔，從來不會多說點東西出來，沒辦法，還只有讓我們自己動手去摳。呵呵。。。
續說上邊提到的介面問題，我是把方法都封裝在介面裡了，如果發生了功能需求變化，豈不是會違背開閉原則，將擁有那麼多方法的介面開啟並更改。有看了看學宇的系統包圖，裡邊眾多的類圖，咦~ ？我就納悶了。。。
為什麼在我初步設計中沒有那麼多類圖，而全封在介面中了，這有點牽一發動全身的效應了。不好，不好呀！
重提「抽象」,讀過乙個人的部落格，他說「抽象就是把『像』的抽出來」，恩！ 「把像的抽出來」，這句話我經常想，其實物件導向更多的亮點也就在抽象層上了，而不走介面(特殊的抽象)路，去走抽象(通常說的抽象類)路，難也不難，不難也難，總共的來說類與類之間的耦合牽連還是不容易一下子就分清的哈。
昨天又找學宇請教分層，通過「二進宮」，我算是初步明了了她的系統設計層次，其中介面和乙個實現層就是為了配合反射(用於方便更改資料庫)來設計的，還有就是出現了乙個資料轉換層，其實這一層就是將眾多原屬乙個物件的資料元素綜合還原為物件原型。這樣在類間傳遞的時候就方便許多。系統分層中最上層的是介面層(也就是接受一些資料，進行一下簡單的邏輯判斷)，剩下的還一層就是實際的資料庫操作層。從模糊角度來看這個系統分層，也就是經典三層，只不過其中有些東西給細化了分出來了。
再看自己的構思，錯誤！ 很正常的錯誤，但卻是致命的錯誤哈。反省中。。。。
經過這次稀里糊塗的跑偏，也使得我慢慢認識了一些分層的東西，其實說來也簡單，封閉、擴充套件等，知識總也是說來簡單，說和做總是有差別難度的。
這次認識到了，改正了，呵呵，又該去認識、去改正了。
機房收費管理系統 之 總結反思
機房開放收費管理系統 後期總結反思 在寫了第乙個機房收費管理系統功能分析表以後，我是這樣想的，既然要模仿現在這個收費管理系統，那麼就要了解它的功能，初步知道了功能，那如何實現這個功能，是什麼技術支援，這些都好說，比較難找的就是這些功能，這些背後的東西，背後的聯絡，各自的細節處理等等這些東西都是需要好...
機房收費系統完美設計 獲得系統時間
為什麼要獲得系統時間？情景 當教師登陸系統向資料庫中新增了工作記錄其中包括登入時間，但隨後有人更改了教師使用的計算機的時間。此後教師的所有操作也需要讀取系統時間存入資料庫。此時如果我們只用簡單度語句 time date.now 讀取系統時間存入資料庫會導致教師登陸的時間晚於教師操作的時間。也就是說教...
機房收費系統重構 介面設計
終於開始做機房收費系統個人版了。最初是想著如何如何複雜，自己前怕狼後怕虎的，哆哆嗦嗦就是下不了手。一畫圖10幾天過去了，一考試乙個星期又過去了。現在總算是入手了，思路也漸漸清晰起來。問題也隨之而來 在做frmmain這個窗體時，新增的textbox和label的大小不隨窗體最大化而改變。找了一些資料...