機房重構---我們“重構”出了什嗎？

           機房重構馬上就要結束了，在這“第三個”系統結束的時候，有必要思考一下我們重構的目的了。

          也許有人說，還有什麼目的呀，不就是程式設計語言換成了.Net，做出來，調完bug,能運行就得了唄。這麼浮誇的日子裡，還叫什麼勁啊。

          對於有這種想法的人，我必須道一聲：您（白）辛苦了 。

          無論做什麼事，沒有一點總結性思考是無法進步的。

          我下面的一些重構論述或者說反思性總結也存在許多不足，希望大家多多指正，在此先致謝。

          本文將從五個方面論述一下這次的重構系統，分別是系統架構、UML圖指導、設計模式應用、資料處理和物件導向。

 

          首先，系統架構方面。

          在這次重構中，我們都運用了三層架構，目的是降低耦合，提高系統的重用性和可維護性等各種目的。在設計中，和第一次機房的基本面向過程編程相比，我們確實也深刻的體會到了有架構的方便和易維護。

          通過添加外觀、SqlHelper、設定檔等基本輔助模組或工具，我們再次體會到了獨立的封裝給我們帶來的巨大便利，從解耦到封裝，就看到了物件導向。

 

          其次，UML圖和文檔的指導。這次重點是放在了UML圖上，使用案例圖、包圖、類圖和時序圖是關鍵。

          包與”三層“、類圖與三層中D層和B層的設計（不同的分類標準，如按資料庫表還是功能進行B層設計）、時序圖對功能執行過程的指導等都是密不可分，需要我們必須提前仔細分析的。當然，這些都是建立在需求分析和用例設計之上的。

 

          再次，設計模式方面。

          現在為止，應用設計模式的痛點在於如何將系統的某個功能或系列功能對應到設計模式中。學習過程中，能夠對各個執行個體理解和形象化描述出來是重點，這樣我們才能更好的對應到以後的系統執行個體分析中。

          在機房重構中，目前我瞭解或使用的設計模式應用有：

          策略模式-對於不同類型的使用者實行不同的計費方法

          抽象工廠+反射-對不同的表進行簡單化切換

          外觀-在U層和B之間的外觀層，進一步解耦，使U層更具獨立性

          模板-類似的表單不需要一遍遍重複的代碼

          適配器-外部報表和vb.net融合

          單例-保證一個表單不被各種new出來

          職責鏈-從一般使用者到操作員再到管理員，總有一個要解決問題

 

          再談談資料處理方面。

          資料處理無論什麼時候都是一個重點需要解決的問題，尤其是在現代大資料時代，效率和安全顯得更為重要。在這次機房重構中，對資料庫一些功能有了更為深入的理解。          

          這裡說兩點。一是在通過第一次做機房的時候對建資料庫的生澀、缺乏必要三範式分析的基礎上進行了第二次資料庫建立和改良。即使在系統編程過程中，有時候還是避免不了去動資料庫，改改欄位，以彌補我們分析的不足和臨時的靈光一現。

          二是當我們一而再，再而三的路過標有“事務、預存程序、觸發器、視圖”等等關鍵詞的路牌時，有必要駐足去探查一番了。預存程序和觸發器執行方便切更符合封裝性特點，事務對系統某些”互相影響“功能的嚴格控制等特點讓我們不得不去探索它們的優點，進而應用。預存程序的應用如上下機、組合查詢等；事務可以考慮用於儲值、結賬方面。

 

          最後，談一下系統與物件導向。

          在這次重構中，體會到了物件導向無處不在的思想優點。

          比如繼承性：管理員對操作員的繼承，操作員對一般使用者的繼承，不僅明確了他們之間的聯絡，還簡化了結構。另外介面的應用也是繼承。

          封裝性就體現的更多了，資料封裝、功能封裝無處不在。一個良好的系統設計需要對物件導向、面向介面有著極為深入的理解，另外，在實際操作過程中進行實踐更是提升我們理解的最佳手段。

 

          總結：對於此次機房重構，還有很多實踐上應用的不足，如何把這些思考通過這次重構，乃至結合下次的合作版實現，才是對經驗最好的補充。這樣在應對下面的學習時，就可以把學習本身作為一個系統進行完美解析和最佳實務了。