第五章
設計模式與軟體架構設計
一、物件導向軟體架構設計思想
a)物件導向正規化
i.物件導向正規化的核心是「物件」的概念
ii.所有的東西都聚焦於物件
iii.
圍繞物件
-而非函式
-組織**
b)物件從不同視角觀察
i.概念層：乙個物件是一系列責任
ii.規格層：乙個物件是一系列可以被其他物件或該物件自己呼叫的方法
iii.
實現層：乙個物件是一些**和資料
c)設計原則
i.「開閉」原則
(ocp)
ii.黎克特制代換原則
(lsp)
iii.
依賴倒轉原則
(dip)
iv.介面隔離原則
(isp)
v.組合
/聚合復用原則
(carp)
vi.迪公尺特法則
(lod)
二、使用
uml進行軟體架構設計
a)最小
uml建模技術
i.對於大多數問題而言，只需使用
20%的
uml，就可以完成
80%的建模工作。
ii.實際中，好像總是沒有足夠的時間來完成建模、分析和設計工作，總是過早地進入到編碼階段。
iii.
足以很好地完成軟體專案工作所需的、最小的
uml和建模技術子集。
b)類圖規定了**的結構
c)時序圖將操作分配給類
d)三、
設計模式的本質論
a)模式是從解決具體問題抽象出來的，這種具體問題在特定的上下文中重複出現。也就是說，每個具體形式都對一種重複的問題採用重複的解決方案。
b)理解設計模式的結果和代價
i.物件過多：設計模式的精髓之一是將可變部分封裝為物件，帶來的好處是系統更加靈活，易於維護，但也大量增加了物件。如果不恰當地使用設計模式，會使系統難以除錯。
1.命令模式：將行為封裝為物件，這樣原來乙個物件中的若干方法變成了若干命令物件。如果將命令模式應用在乙個
gui使用者介面上，每乙個選單項就要生成乙個命令物件，原來由乙個物件完成的工作現在可能需要十幾個物件來完成。
2.狀態模式：將不同的狀態封裝為物件，原來可能是通過判斷語句完成的工作分散到各個物件中完成。由於狀態是動態決定的，因此在設計測試用例時有難度。
ii.更複雜的裝配關係：很多設計模式依賴物件之間的關係，因此在初始化時需要執行相應的裝配工作，需要裝配物件的模式有如下幾種。
1.生成器模式：需要裝配生成器和導航器。
2.橋接模式：需要將代表邏輯的物件和代表實現的物件進行裝配。
3.觀察者模式：需要將不同的觀察者物件關聯在一起。
4.職責鏈模式：需要組裝整條職責鏈。
iii.
測試難度加大：這是前面兩個結果導致的，由於物件的增多和物件間關係的複雜，因此測試用例的設計難度增大。特別是很多邏輯上的錯誤可能由裝配關係不當造成，並且在編譯時很難發現。解決測試難度大的方法是將測試用例文件化，即繪製測試用例的物件圖。這個話題超出了本書的範圍，有興趣的讀者可參考相關書籍。
iv.程式結構複雜：設計模式關注的是如何使軟體更具可維護性，因此從結構上已經與原始的需求完全不同。加上很多功能是通過物件的動態組合實現的，程式的動態結構變得與靜態結
v.構同樣重要。從單純的靜態結構
(例如類圖
)已經很難理解實現的方式和最終的意圖了，這也是經常是使用設計模式的代價之一。
c)設計模式不能做什麼
i.設計模式不是法則
模式理論的精髓之一就是模式的使用是有前提和代價的，模式是在某種前提下，綜合各方面因素後考慮得出的結果。即在使用模式時總是要付出一定的代價，當然這種代價是可以接受的。如果某個模式在所有場合中的使用都是必然的，那麼它就不能叫做模式了，而是一種必
須遵守的法則。例如「面向介面，而非實現程式設計」，是法則而非模式。
ii.不能提高開發速度或者形象開發速度
《高階軟體架構師講義》學習筆記1
物件導向應用建模 的實踐過程有 3個階段 1.有步驟 分層次地演進系統構架 2.將軟體需求逐漸轉變為軟體的設計方案 3.保障軟體的設計方案能夠適應實施環境 應用建模實踐過程由五項 任務 組成 1.全域性分析 2.區域性分析 3.全域性設計 4.區域性設計 5.細節設計 這其中，前兩項任務以分析為核心...
《高階軟體架構師講義》學習筆記第二章
一 軟體架構模版設計 1.體系結構設計原則 a.合適性 即體系結構是否適合於軟體的 功能性需求 和 非功能性需求 高水平的設計師高就高在 設計出恰好滿足客戶需求的軟體，並且使開發方和客戶方獲取最大的利益，而不是不惜代價設計出最先進的軟體。選擇能夠為開發方和客戶方帶來最大利益的那個設計方案。b.結構穩...
軟體架構設計 架構師筆記，軟體架構設計
架構設計是分與合的藝術 通讀並總結了溫昱老師的 軟體架構設計 並有幸聽過李哲珠博士對架構設計的講解。對其讀後的自我領悟並提煉出核心內容分享出來，希望從思想高度上能提公升你對軟體架構設計的認知。架構設計 架構設計不等於框架設計，框架也可能有架構，所有的原子元件 被拆分的模組 都需要架構設計，所有元件可...