這次合作開發過程中我們使用了一些設計模式,經過討論對其理解深刻不少。之前在學習之中,我本以為自己已經理解了一些設計模式。但在這次的使用過程中,因為各自的理解不一造成了一定的碰撞,之后才發現自己的理解根本就站不住腳。于是,反復經過我們的討論——實施——再討論,發現理解的偏差,解決之。然后,才有了目前我們認為的比較穩定的,符合邏輯的理解。本篇博客要說的是我對狀態模式和職責鏈模式的理解。這兩個設計模式看上去不一樣,實施起來卻又貌似很相似,所以不認真的話很容易迷糊。?
狀態模式:我們用于學生上機時的判斷。四個子狀態分別為:卡號不存在(CardNoExitStateBLL),卡號存在余額不足(LeastCashStateBLL),卡號已上機(isOnlineStateBLL),上機成功(SuccessOnlineBLL)。

職責鏈模式:用于刪除用戶時,對用戶是否還有未結的帳,是否在線的檢查判斷。四個管理者子類分別為:用戶是否在線(IsworkingHandlerBLL),是否有未結賬的充值(RechargeIsCheckHandlerBLL),退卡是否有未結的賬(CancelCardISCheckHandlerBLL),注冊是否有未結的帳。

相同點:
兩個設計模式從類圖結構上粗看是完全不一樣的。但是實際上在處理一個問題時各個類之間的通信或者說任務遞交是一樣的,都是鏈式的一個順序。特別是在代碼上實現時,稍不注意兩個模式就會混為一談,因為圖上的巨大區別反應在代碼是只有關鍵的一句或者幾句。這種在實現上的理解模糊很讓人難受。由于兩個模式加起來代碼比較長,那么下面配兩幅圖來說明這個兩個模式的區別。
狀態模式:實際上子狀態是從單個類中獨立出去的,因此其整體的功能是一個完整的類的功能。只不過我們把這個類對不同情況的響應寫在了一個類中,致使其擴展性不好。所以我們,才把它的不同響應行為獨立成狀態子類,以賦予它良好的對新需求的擴展性。其本質是,一個類對不同狀態的多種不同響應。

職責鏈模式:實際上是在應對處理一個或者一類問題上的結構性優化。是多個管理者在處理一個問題上森嚴的等級關系。每個管理者,都只有能處理或者不能處理兩種情況。那么,管理者或者說等級關系可能是不穩定的。職責鏈的本質是,不同的類對同一個問題的反應。

不同點:從以上兩幅圖可以清楚的看出來,狀態模式的子類只負責改變其擁有類的狀態屬性,而不負責去執行下一個狀態的方法。執行還需要通過擁有他的類去調用下個狀態子類的方法。而職責鏈模式的每個管理者則是既負責處理問題也負責請求的遞交。這是,我覺得他們最大的區別。這兩個模式是從一個問題的不同的角度的處理。一個從問題的角度,一個從處理者的角度。
總結:三個湊皮匠頂個諸葛亮,學習還是需要不同的理解的碰撞,才能夠引起新的思考。若不然,則會再自己的思維模式中釘死。