設計模式概述——測試羣發

一、設計模式問題以及目的

程序員編寫軟件過程當中，面臨 耦合性、內聚性以及可維護性，可擴展性，重用性，靈活性等問題，設計模式就是爲了讓程序有更好的：

• 1) ==代碼重用性==(即：相同功能的代碼，不用屢次編寫)
• 2) ==可讀性== (即：編程規範性, 便於其餘程序員的閱讀和理解)
• 3) ==可擴展性== (即：當須要增長新的功能時，很是的方便，稱爲可維護)
• 4) ==可靠性== (即：當咱們增長新的功能後，對原來的功能沒有影響)
• 5) ==使程序呈現高內聚，低耦合的特性==

分享金句：

設計模式包含了面向對象的精髓，「懂了設計模式，你就懂了面向對象分析和設計（OOA/D）的精要」

Scott Mayers 在其鉅著《Effective C++》就曾經說過：C++老手和 C++新手的區別就是前者手背上有不少傷疤

二、設計模式原則

設計模式原則，其實就是程序員在編程時，應當遵照的原則，也是各類設計模式的基礎(即：設計模式爲何這樣設計的依據)

==1) 單一職責原則【Single-Responsibility Principle】：==

對類來講的，即一個類應該只負責一項職責。如類 A 負責兩個不一樣職責：職責 1，職責 2。當職責 1 需求變動而改變 A 時，可能形成職責 2 執行錯誤，因此須要將類 A 的粒度分解爲 A1，A2

==2) 接口隔離原則【Interface Segregation Principle】：==

客戶端不該該依賴它不須要的接口，即一個類對另外一個類的依賴應該創建在最小的接口上。

• 1) 類 A 經過接口 Interface1 依賴類 B，類 C 經過接口 Interface1 依賴類 D，若是接口 Interface1 對於類 A 和類 C來講不是最小接口，那麼類 B 和類 D 必須去實現他們不須要的方法。
• 2) 按隔離原則應當這樣處理：將接口 Interface1 拆分爲獨立的幾個接口(這裏咱們拆分紅 3 個接口)，類 A 和類 C 分別與他們須要的接口創建依賴關係。也就是採用接口隔離原則

==3) 依賴倒轉(倒置)原則【Dependence Inversion Principle】：==

• 1) 高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象
• 2) 抽象不該該依賴細節，細節應該依賴抽象
• 3) 依賴倒轉(倒置)的中心思想是面向接口編程
• 4) 依賴倒轉原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建的架構比以細節爲基礎的架構要穩定的多。在 java 中，抽象指的是接口或抽象類，細節就是具體的實現類
• 5) 使用接口或抽象類的目的是制定好規範，而不涉及任何具體的操做，把展示細節的任務交給他們的實現類去完成

  注意：

  低層模塊儘可能都要有抽象類或接口，或者二者都有，程序穩定性更好.

  變量的聲明類型儘可能是抽象類或接口, 這樣咱們的變量引用和實際對象間，就存在一個緩衝層，利於程序擴展和優化

  繼承時遵循里氏替換原則

==4) 里氏替換原則【Liskov Substitution Principle】：==

• 1) 繼承在給程序設計帶來便利的同時，也帶來了弊端。好比使用繼承會給程序帶來侵入性，程序的可移植性下降， 增長對象間的耦合性，若是一個類被其餘的類所繼承，則當這個類須要修改時，必須考慮到全部的子類，而且父類修改後，全部涉及到子類的功能都有可能產生故障，在編程中，如何正確的使用繼承? => 里氏替換原則
• 2) 若是對每一個類型爲 T1 的對象 o1，都有類型爲 T2 的對象 o2，使得以 T1 定義的全部程序 P 在全部的對象 o1 都代換成 o2 時，程序 P 的行爲沒有發生變化，那麼類型T2 是類型 T1 的子類型。換句話說，全部引用基類的地方必須能透明地使用其子類的對象。
• 3) 在使用繼承時，遵循里氏替換原則，在子類中儘可能不要重寫父類的方法
• 4）里氏替換原則告訴咱們，繼承實際上讓兩個類耦合性加強了，在適當的狀況下，能夠經過聚合，組合，依賴 來解決問題。

==5) 開閉原則【Open Closed Principle】：==

• 1) 開閉原則（Open Closed Principle）是編程中最基礎、最重要的設計原則
• 2) 一個軟件實體如類，模塊和函數應該對擴展開放(對提供方)，對修改關閉(對使用方)。用抽象構建框架，用實現擴展細節。
• 3) 當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化。
• 4） 編程中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則。

==6) 迪米特法則【Demeter Principle】：==

• 1) 一個對象應該對其餘對象保持最少的瞭解
• 2) 類與類關係越密切，耦合度越大
• 3) 迪米特法則(Demeter Principle)又叫最少知道原則，即一個類對本身依賴的類知道的越少越好。也就是說，對於被依賴的類無論多麼複雜，都儘可能將邏輯封裝在類的內部。對外除了提供的 public 方法，不對外泄露任何信息
• 4) 迪米特法則還有個更簡單的定義：只與直接的朋友通訊
• 5） 直接的朋友：每一個對象都會與其餘對象有耦合關係，只要兩個對象之間有耦合關係，咱們就說這兩個對象之間是朋友關係。耦合的方式不少，依賴，關聯，組合，聚合等。其中，咱們稱出現成員變量，方法參數，方法返回值中的類爲直接的朋友，而出如今局部變量中的類不是直接的朋友。也就是說，陌生的類最好不要以局部變量的形式出如今類的內部。

==7) 合成複用原則【Composite Reuse Principle】：==

1） 原則是儘可能使用合成/聚合的方式，而不是使用繼承

• A中有三個方法，B中想要使用A中的方法
• 方式一：B繼承A
• 方式二：operation1(A a) （合成）
• 方式三：A a setA(A a) （聚合）
• 方式四：A a = new A() （組合）

總的原則：

• 1) 找出應用中可能須要變化之處，把它們獨立出來，不要和那些不須要變化的代碼混在一塊兒。
• 2) 針對接口編程，而不是針對實現編程。
• 3) 爲了交互對象之間的鬆耦合設計而努力

三、UML圖

分類：

• 1) 用例圖(use case)
• 2) 靜態結構圖：類圖、對象圖、包圖、組件圖、部署圖
• 3) 動態行爲圖：交互圖（時序圖與協做圖）、狀態圖、活動圖
• Ø 說明：類圖是描述類與類之間的關係的，是 UML 圖中最核心的

關係：

• ==dependency 依賴關係==：Ø 只要是在類中用到了對方，那麼他們之間就存在依賴關係。若是沒有對方，連編繹都經過不了。
• ==associaion 關聯關係==：Ø 實際上就是類與類之間的聯繫，他是依賴關係的特例 單向一對一 雙向一對一 多對多
• ==generalization 泛化關係==：Ø 實際上就是繼承關係，他是依賴關係的特例
• ==realizaiton 實現關係==：Ø 實際上就是 A 類實現 B 接口，他是依賴關係的特例
• ==aggregation 聚合關係==：Ø 表示的是總體和部分的關係，總體與部分能夠分開。聚合關係是關聯關係的特例，因此他具備關聯的導航性與多重性。
• ==composite 組合關係==：Ø 也是總體與部分的關係，可是總體與部分不能夠分開。 類中：new 其餘對象，若是類失效了，那麼其中的對象也失效。

四、總結

下面用一個圖片來總體描述一下設計模式之間的關係：

==建立型模式：關注對象的建立==

==結構型模式：站在軟件結構的立場上，讓軟件結構更具備伸縮性，擴展性==

==行爲型模式：關注方法層面的設計==