最近開工了機房收費系統重構版，确實是有點糾結。
因為這一次是完全應用面向對象的思想設計程式。雖然之前學習了很多次面向對象程式設計，但是到實際應用的時候，還是會感到無從下手。糾結也沒用，因為生活還在繼續。。
機房收費系統，先從uml模組化開始說起，剛剛畫完包圖和用例圖，現在在頭疼類圖，說到類圖,那真是無所适從，怎麼抽象出類?添加什麼屬性?應該有什麼方法?類直接又改怎麼聯系?等等肯定不能像第一次畫圖那樣胡扯…沒關系隻要去做，所有的問題都不是問題！
說到包圖，雖說包圖比較簡單，心裡也明白要按照剛學的三層思想來設計包圖，但是具體怎麼做呢？還是不懂，通過查閱資料稍稍了解了一些：
這就是機房收費系統的三層包圖。多麼簡單挺清晰！
但就是如此就可以了嗎？
答案是 Ｎo！
我們都知道包圖，展現的是整個系統的架構，而系統的架構應該是相對穩定的,或者說能夠良好的适應變化的.因為架構一變,代碼必定傷筋動骨!這樣就會導緻成本上升、工期延長。這種結果我們肯定不願看見。那麼怎麼才能隔離或者掌控這種變化呢？
上個月剛剛學習了《大話設計模式》，設計模式一共有23種；根據模式的應用目的，又将它們分為3 類：建立型、結構型和行為型。回顧一下。另外在課本的第１４頁，我發現了這麼一句話“重要的不是你将來會不會用到這些模式，而是通過這些模式讓你找到“封裝變化”，“對象間松散耦合”，“針對接口程式設計”的感覺，進而設計出以維護，易擴充，易複用，靈活性好的程式。”仔細想想“對象間松散耦合”，“針對接口程式設計”的目的也是為了封裝變化，是以設計模式的作用則可以概括為四個字：“封裝變化”
這個作用正好和架構設計的難題“隔離變化”有點一拍即合的感覺。當然事實也正是如此，設計模式可以封裝變化，幫助架構“未雨綢缪”。
總的來說：要讓設計的架構能适應變化，就是要預見元件之間的互動接口和編碼實作将來可能發生什麼變化，并對此做出正确的決策：采用正确的設計模式去封裝變化。
在機房收費系統中的展現：
如圖是加入設計模式後的包圖，ifactory（抽象工廠）和ＩＤＡＬ（ＤＡＬ的接口）是為了預防資料庫的變更。
Ｆａｃａｄｅ（外觀模式）是為了Ｕ層和Ｂ層松耦合。
大家可能會有疑問：程式中用到的設計模式都要展現在包圖上嗎？
答案是：Ｎｏ！
實際上我在構思重構版的時候還考慮到了應用政策模式和狀态模式。但是為什麼沒有添加到上圖中呢？這還要考慮這些模式的實際應用。政策模式的作用是封裝算法，讓算法的變化不影響使用它的客戶。而這些算法邏輯都放在ＢＬＬ層（業務邏輯層）是以政策模式可以作為包ＢＬＬ的一個子包而存放其中，不存在調用關系。
說到調用關系，這也是包圖的一個非常重要的地方。包之間是否存在調用關系，以及調用的方向都需要我們仔細的斟酌。
包圖就先說到這吧，第一次學習包圖的時候，怎麼沒發現原來包圖也有這麼大的學問！循循漸進沒發現的還有很多。。。