《高級軟件架構師講義》學習筆記5

?第五章???? 設計模式與軟件架構設計

?

一、面向對象軟件架構設計思想

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.????????????? 不能提高開發速度或者形象開發速度

? 如果以一個開發周期作為考核標準，恐怕沒有人會使用設計模式。設計模式并不能提高目前的開發速度，至少其關注的目標并不是開發速度。很多情況下甚至會降低開發速度，即使是正確地選擇了設計模式。

? 這是因為設計模式可能會引入更多的對象和更復雜的對象裝配關系，從而使得程序有更多的動態狀態，從局部看來變得結構復雜，難以理解并且測試困難。如果僅僅關注于形象進度，或者能夠百分之百地確定需求沒有變化，那么設計模式并不是很好的選擇。

????????????????????? iii.????????????? 不是萬能的

?設計模式的使用是自然而然的事情，很多情況下不使用設計模式是因為不需要，問題還沒有復雜到非用不可的程度。我們是為了設計而使用設計模式，而不是為了使用設計模式而設計。

? 當你的項目發現有如下問題之一時，就需要考慮重構代碼，可能會有某種模式適合。

? (1)代碼無法進行單元測試。

? (2)需求的變動總是導致代碼的變動。

? (3)有重復代碼存在。

? (4)繼承層次過多。

? (5)隱藏的依賴過多。

四、設計模式與架構模式

a)???????? 主要架構模式

???????????????????????? i.????????????? 流程處理模式

?????????????????????? ii.????????????? 客戶/服務器模式、

????????????????????? iii.????????????? 模型—視圖—控制器模式(MVC)

???????????????????? iv.????????????? 分層模式

b)??????? 確立軟件架構考慮的因素

???????????????????????? i.????????????? 架構中包的數量

?????????????????????? ii.????????????? 架構中包之間的耦合度

????????????????????? iii.????????????? 軟件元素的穩定性

???????????????????? iv.????????????? 軟件元素的分類

?????????????????????? v.????????????? 作為軟件系統運行環境的物理網絡拓樸

???????????????????? vi.????????????? 軟件元素的安全、保密級別

??????????????????? vii.????????????? 開發團隊的技術專長

????????????????? viii.????????????? 調整軟件架構，支持并行開發

看了這里之后才了解MVC模式與GOF那些設計模式有什么區別，
MVC模式屬于架構模式，特別適合應用于分布式應用系統。
大型軟件的頂層架構往往需要使用多種架構樣式。如，整個目標軟件系統采用分層結構，在系統的不同層次內再分別使用適宜的其他類型的架構模式。

?