??? 最近開工了機房收費系統重構版，確實是有點糾結。

????因為這一次是完全應用面向對象的思想設計程序。雖然之前學習了很多次面向對象編程，但是到實際應用的時候，還是會感到無從下手。糾結也沒用，因為生活還在繼續。。

??? 機房收費系統，先從UML建模開始說起，剛剛畫完包圖和用例圖，現在在頭疼類圖，說到類圖,那真是無所適從，怎么抽象出類?添加什么屬性?應該有什么方法?類直接又改怎么聯系?等等肯定不能像第一次畫圖那樣胡扯…沒關系只要去做，所有的問題都不是問題！

?

??? 說到包圖，雖說包圖比較簡單，心里也明白要按照剛學的三層思想來設計包圖，但是具體怎么做呢？還是不懂，通過查閱資料稍稍了解了一些：

????????????

??? 這就是機房收費系統的三層包圖。多么簡單挺清晰！

但就是如此就可以了嗎？

??? 答案是　Ｎo！

??? 我們都知道包圖，體現的是整個系統的架構，而系統的架構應該是相對穩定的,或者說能夠良好的適應變化的.因為架構一變,代碼必定傷筋動骨!這樣就會導致成本上升、工期延長。這種結果我們肯定不愿看見。那么怎么才能隔離或者掌控這種變化呢？

??? 上個月剛剛學習了《大話設計模式》，設計模式一共有23種；根據模式的應用目的，又將它們分為3 類：創建型、結構型和行為型?；仡櫼幌?。另外在課本的第１４頁，我發現了這么一句話“重要的不是你將來會不會用到這些模式，而是通過這些模式讓你找到“封裝變化”，“對象間松散耦合”，“針對接口編程”的感覺，從而設計出以維護，易擴展，易復用，靈活性好的程序?！?/span>仔細想想“對象間松散耦合”，“針對接口編程”的目的也是為了封裝變化，所以設計模式的作用則可以概括為四個字：“封裝變化”

??? 這個作用正好和架構設計的難題“隔離變化”有點一拍即合的感覺。當然事實也正是如此，設計模式可以封裝變化，幫助架構“未雨綢繆”。

??? 總的來說：要讓設計的架構能適應變化，就是要預見組件之間的交互接口和編碼實現將來可能發生什么變化，并對此做出正確的決策：采用正確的設計模式去封裝變化。

?

在機房收費系統中的體現：

??? 如圖是加入設計模式后的包圖，IFactory（抽象工廠）和ＩＤＡＬ（ＤＡＬ的接口）是為了預防數據庫的變更。

Ｆａｃａｄｅ（外觀模式）是為了Ｕ層和Ｂ層松耦合。

??? 大家可能會有疑問：程序中用到的設計模式都要體現在包圖上嗎？

??? 答案是：Ｎｏ！

??? 實際上我在構思重構版的時候還考慮到了應用策略模式和狀態模式。但是為什么沒有添加到上圖中呢？這還要考慮這些模式的實際應用。策略模式的作用是封裝算法，讓算法的變化不影響使用它的客戶。而這些算法邏輯都放在ＢＬＬ層（業務邏輯層）所以策略模式可以作為包ＢＬＬ的一個子包而存放其中，不存在調用關系。

?

??? 說到調用關系，這也是包圖的一個非常重要的地方。包之間是否存在調用關系，以及調用的方向都需要我們仔細的斟酌。

?

??? 包圖就先說到這吧，第一次學習包圖的時候，怎么沒發現原來包圖也有這么大的學問！循循漸進沒發現的還有很多。。。

?

?

總結

以上是生活随笔為你收集整理的包图+设计模式？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。