第五章
設計模式與軟體架構設計
一、物件導向軟體架構設計思想
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.結構穩...
軟體架構設計 架構師筆記,軟體架構設計
架構設計是分與合的藝術 通讀並總結了溫昱老師的 軟體架構設計 並有幸聽過李哲珠博士對架構設計的講解。對其讀後的自我領悟並提煉出核心內容分享出來,希望從思想高度上能提公升你對軟體架構設計的認知。架構設計 架構設計不等於框架設計,框架也可能有架構,所有的原子元件 被拆分的模組 都需要架構設計,所有元件可...