ln
專案截止到昨天為止算是徹底的完工了，功能實現方面沒有問題，但是這個一星期出來的「早產兒」還是有很多其他問題，比如**的重複量過高、各個類之間耦合太大。整個系統中雖然用到了分層的思想，但是基本上
bll層的**是一致的，也就是說如果需求改動（比如增加審核的部門，或者原先的部門審核順序進行調整）則需要改動整個的
bll層。
現在整個系統的架構如下圖所示:
整體上的架構沒什麼問題，經典的
mvc。其實這次做的系統有點四不像，巨集觀的看是
mvc但是具體到
model
層我們又走了
.net
中的三層架構的老路子，這就導致了每個
servlet
對應各自的
bll，於是就造成了
bll層的重複**太多。
duplicate code
（重複**）是
**的壞味道
之一（「**的壞味道」——引用自《
重構》）。
於是……
通過對整個
ln系統的分析可以看出來這個系統就是乙個職責鏈，首先是使用者填寫申請資訊，然後由各個部門一級一級的進行審批，最終得到通過（或者進行駁回）。儘管和經典的設計模式當中的職責鏈模式不是一模一樣但是不影響我們用職責鏈模式對系統進行重構。
嘗試用職責鏈模式重構
bll層之後的部分類圖如下圖：
根據從資料庫得來的各個部門的簽署意見，將這些意見賦值到實體類中，根據這些意見判斷此次申請被那些部門審核過，同時判斷審核是否通過。這裡簡化**沒有涉及
dal以及
sqlhelper
的**部分，只將結果進行列印輸出，核心**如下：
執行結果如下圖:
通過重構後如果系統在原來的基礎上增加或者調整部門的先後審核順序則只需要增加
bll類或者調整
servlet
中對bll
層的先後呼叫關係即可。這樣的話無需改動整個的
b層，而且可以清晰的看到在
servlet
呼叫bll
的時候只需要操縱整條職責鏈中的第乙個鏈即可，不與其他的類發生關係，大大的降低了耦合，提高了**的復用性，有利於後期的維護（藍色部分為物件導向的套話）。
LN專案重構之職責鏈模式
ln 專案截止到昨天為止算是徹底的完工了，功能實現方面沒有問題，但是這個一星期出來的 早產兒 還是有很多其他問題，比如 的重複量過高 各個類之間耦合太大。整個系統中雖然用到了分層的思想，但是基本上bll 層的 是一致的，也就是說如果需求改動 比如增加審核的部門，或者原先的部門審核順序進行調整 則需要...
LN專案重構之職責鏈模式
ln 專案截止到昨天為止算是徹底的完工了，功能實現方面沒有問題，但是這個一星期出來的 早產兒 還是有很多其他問題，比如 的重複量過高 各個類之間耦合太大。整個系統中雖然用到了分層的思想，但是基本上bll 層的 是一致的，也就是說如果需求改動 比如增加審核的部門，或者原先的部門審核順序進行調整 則需要...
重構 下機 職責鏈模式
使用者下機，進行金錢和時間的計算，需要進行多重判斷 在責任鏈模式裡，很多物件由每乙個物件對其下家的引用而連線起來形成一條鏈。請求在這個鏈上傳遞，直到鏈上的某乙個物件決定處理此請求。發出這個請求的客戶端並不知道鏈上的哪乙個物件最終處理這個請求，這使得系統可以在不影響客戶端的情況下動態地重新組織和分配責...