Java內功心法之設計模式學習(一）

1、設計模式七大原則

一、設計模式的目的

編寫軟件過程當中，程序員面臨着來自 耦合性，內聚性以及可維護性，可擴展性，重用性，靈活性 等多方面的挑戰，設計模式是爲了讓程序(軟件)，具備更好

• 1) 代碼重用性 (即：相同功能的代碼，不用屢次編寫)
• 2) 可讀性 (即：編程規範性, 便於其餘程序員的閱讀和理解)
• 3) 可擴展性 (即：當須要增長新的功能時，很是的方便，稱爲可維護)
• 4) 可靠性 (即：當咱們增長新的功能後，對原來的功能沒有影響)
• 5) 使程序呈現高內聚，低耦合的特性分享金句：
• 6) 設計模式包含了面向對象的精髓，「懂了設計模式，你就懂了面向對象分析和設計（OOA/D）的精要」
• 7) Scott Mayers 在其鉅著《Effective C++》就曾經說過：C++老手和 C++新手的區別就是前者手背上有不少傷疤

二、設計模式七大原則

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

➢設計模式經常使用的七大原則有:

• 一、單一職責原則
• 二、接口隔離原則
• 三、依賴倒轉原則
• 四、里氏替換原則
• 五、開閉原則 ocp
• 六、迪米特法則
• 七、合成複用原則

2.1 單一職責原則

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

單一職責原則注意事項和細節：
1) 下降類的複雜度，一個類只負責一項職責。
2) 提升類的可讀性，可維護性
3) 下降變動引發的風險
4) 一般狀況下，咱們應當遵照單一職責原則，只有邏輯足夠簡單，才能夠在代碼級違反單一職責原則；只有類中方法數量足夠少，能夠在方法級別保持單一職責原則

2.2 接口隔離原則(Interface Segregation Principle)

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

2.3 依賴倒轉原則

依賴倒轉原則(Dependence Inversion Principle)是指：

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

示例

方案1，普通示例（未使用依賴倒轉）：

package com.atguigu.principle.inversion;

public class DependecyInversion {

   public static void main(String[] args) { 
   Person person = new Person(); 
   person.receive(new Email());
}

}

class Email {
   public String getInfo() {
     return "電子郵件信息: hello,world";
   }
}

//完成 Person 接收消息的功能
//方式 1 分析
//1. 簡單，比較容易想到
//2. 若是咱們獲取的對象是 微信，短信等等，則新增類，同時 Perons 也要增長相應的接收方法
//3. 解決思路：引入一個抽象的接口 IReceiver, 表示接收者, 這樣 Person 類與接口 IReceiver 發生依賴
//    由於 Email, WeiXin 等等屬於接收的範圍，他們各自實現 IReceiver 接口就 ok,  這樣咱們就符號依賴倒轉原則
class Person {
   public void receive(Email email ) { 
     System.out.println(email.getInfo());
   }
}

實現方案2（依賴倒轉）

package com.atguigu.principle.inversion.improve;

public class DependecyInversion {

public static void main(String[] args) {

  //客戶端無需改變
  Person person = new Person();
  person.receive(new Email());

  person.receive(new WeiXin());
}

}

//定義接口
interface IReceiver { 
    public String getInfo();
}

class Email implements IReceiver { 
   public String getInfo() {
     return "電子郵件信息: hello,world";
}
}
 

//增長微信
class WeiXin implements IReceiver { 
   public String getInfo() {
     return "微信信息: hello,ok";
   }
}

//方式 2
class Person {
//這裏咱們是對接口的依賴
public void receive(IReceiver receiver ) {  
   System.out.println(receiver.getInfo());
}
}

依賴倒轉原則的注意事項和細節:
1) 低層模塊儘可能都要有抽象類或接口，或者二者都有，程序穩定性更好.
2) 變量的聲明類型儘可能是抽象類或接口, 這樣咱們的變量引用和實際對象間，就存在一個緩衝層，利於程序擴展和優化
3) 繼承時遵循里氏替換原則

2.4 里氏替換原則

2.4.1 OO 中的繼承性的思考和說明

1) 繼承包含這樣一層含義：父類中凡是已經實現好的方法，其實是在設定規範和契約，雖然它不強制要求全部的子類必須遵循這些契約，可是若是子類對這些已經實現的方法任意修改，就會對整個繼承體系形成破壞。

2) 繼承在給程序設計帶來便利的同時，也帶來了弊端。好比使用繼承會給程序帶來侵入性，程序的可移植性下降， 增長對象間的耦合性，若是一個類被其餘的類所繼承，則當這個類須要修改時，必須考慮到全部的子類，而且父類修改後，全部涉及到子類的功能都有可能產生故障

3) 問題提出：在編程中，如何正確的使用繼承? => 里氏替換原則

2.4.2 基本介紹

1) 里氏替換原則(Liskov Substitution Principle)在 1988 年，由麻省理工學院的覺得姓裏的女士提出的。
2) 若是對每一個類型爲 T1 的對象 o1，都有類型爲 T2 的對象 o2，使得以 T1 定義的全部程序 P 在全部的對象 o1 都代換成 o2 時，程序 P 的行爲沒有發生變化，那麼類型 T2 是類型 T1 的子類型。換句話說，全部引用基類的地方必須能透明地使用其子類的對象。

3) 在使用繼承時，遵循里氏替換原則，在子類中儘可能不要重寫父類的方法
4) 里氏替換原則告訴咱們，繼承實際上讓兩個類耦合性加強了，在適當的狀況下，能夠經過聚合，組合，依賴來解決問題。

2.5 開閉原則

2.5.1 基本介紹

1) 開閉原則（Open Closed Principle）是編程中最基礎、最重要的設計原則
2) 一個軟件實體如類，模塊和函數應該對擴展開放(對提供方)，對修改關閉(對使用方)。用抽象構建框架，用實現擴展細節。

3) 當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化。
4) 編程中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則。

2.6 迪米特法則

2.6.1 基本介紹

1) 一個對象應該對其餘對象保持最少的瞭解
2) 類與類關係越密切，耦合度越大
3) 迪米特法則(Demeter Principle)又叫最少知道原則，即一個類對本身依賴的類知道的越少越好。也就是說，對於被依賴的類無論多麼複雜，都儘可能將邏輯封裝在類的內部。對外除了提供的 public 方法，不對外泄露任何信息
4) 迪米特法則還有個更簡單的定義：只與直接的朋友通訊

5) 直接的朋友：每一個對象都會與其餘對象有耦合關係，只要兩個對象之間有耦合關係，咱們就說這兩個對象之間是朋友關係。耦合的方式不少，依賴，關聯，組合，聚合等。其中，咱們稱出現成員變量，方法參數，方法返回值中的類爲直接的朋友，而出如今局部變量中的類不是直接的朋友。也就是說，陌生的類最好不要以局部變量的形式出如今類的內部。

2.6.2 迪米特法則注意事項和細節

1) 迪米特法則的核心是下降類之間的耦合
2) 可是注意：因爲每一個類都減小了沒必要要的依賴，所以迪米特法則只是要求下降類間(對象間)耦合關係， 並非要求徹底沒有依賴關係

2.7 合成複用原則（Composite Reuse Principle）

2.7.1 基本介紹

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

三、設計原則核心思想

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

2、UML類圖

1 UML 基本介紹

• 1) UML——Unified modeling language UML (統一建模語言)，是一種用於軟件系統分析和設計的語言工具，它用於幫助軟件開發人員進行思考和記錄思路的結果
• 2) UML 自己是一套符號的規定，就像數學符號和化學符號同樣，這些符號用於描述軟件模型中的各個元素和他們之間的關係，好比類、接口、實現、泛化、依賴、組合、聚合等，如右圖

在UML類圖中，常見的有如下幾種關係: 泛化（Generalization）, 實現（Realization），關聯（Association)，聚合（Aggregation），組合(Composition)，依賴(Dependency)

先看看UML圖的基本關係表示:

關係說明：

• 繼承關係(Generalization)；
• 實現關係(Realization)；
• 依賴關係(Dependency)；
• 關聯關係(Association)；
• 有方向的關聯(DirectedAssociation)；
• 聚合關係(Aggregation)；
• 組合關係(Composition)；

---

相關文章：

快速學習UML類圖查看