設計模式學習總結（一）——設計原則與UML統一建模語言

一、概要

設計模式（Design Pattern）是一套被反復使用、多數人知曉的、經過分類的、代碼設計經驗的總結。

使用設計模式的目的：為了代碼可重用性、讓代碼更容易被他人理解、保證代碼可靠性。 設計模式使代碼編寫真正工程化；設計模式是軟件工程的基石脈絡，如同大廈的結構一樣。可復用、可擴展、可維護

設計模式是GOF（Group Of Four Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides ）所著的《設計模式：可復用面向對象軟件的基礎》一書中所描述的23種經典設計模式，此書奠定了模式在軟件行業中的地位，從此人們提到“設計模式”就是默認指“面向對象設計模式”

1.1、設計模式定義

每一個模式描述了一個在我們周圍不斷重復發生的問題，以及該問題的解決方案的核心
特定的問題，特定的解決套路

1.2、設計模式分類

設計模式分為三大類共23種：

創建型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型模式，共七種：適配器模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

1.3、設計模式書籍

Head First設計模式(中文版)HEAD FIRST Jolt震撼大獎headfirst設計模式深入淺出講清 java設計模式計算機編程自學入門

大話設計模式

二、UML統一建模語言

 統一建模語言（UML，Unified Modeling Language）是面向對象軟件的標准化建模語言。UML因其簡單、統一的特點，而且能表達軟件設計中的動態和靜態信息，目前已成為可視化建模語言的工業標准。在軟件無線電系統的開發過程中，統一建模語言可以在整個設計周期中使用，幫助設計者縮短設計時間，減少改進的成本，使軟硬件分割最優。

2.1、UML分類

UML定義了5類，10種模型圖、五種類圖定義：

1.用例圖：從用戶角度描述系統功能，並指各功能的操作者。

2.靜態圖：包括類圖，包圖，對象圖。

類圖：描述系統中類的靜態結構

包圖：是包和類組成的，表示包與包之間的關系，包圖描述系統的分層結構

對象圖：是類圖的實例

3.行為圖：描述系統動態模型和對象組成的交換關系。包括狀態圖和活動圖

活動圖：描述了業務實現用例的工作流程

狀態圖：是描述狀態到狀態控制流，常用於動態特性建模

4.交互圖：描述對象之間的交互關系

順序圖：對象之間的動態合作關系，強調對象發送消息的順序，同時顯示對象之間的交互

合作圖：描述對象之間的協助關系

5.實現圖：

配置圖：定義系統中軟硬件的物理體系結構

十種模型圖定義：

(1)、用例圖：展示系統外部的各類執行者與系統提供的各種用例之間的關系

(2)、類圖：展示系統中類的靜態結構

(3)、對象圖：是類圖的一種實例化圖(對象圖是對類圖的一種實例化)

(4)、包圖：是一種分組機制。在UML1.1版本中，包圖不再看作一種獨立的模型圖)

2.2、類圖

建模工具：Rose

COCOMO，英文全稱為constructive cost model，中文為構造性成本模型。它是一種精確、易於使用的，基於模型的成本估算方法。

2.2.1、關聯

在IDEA中查看類圖：

顯示細節

雙向關聯：
C1-C2：指雙方都知道對方的存在，都可以調用對方的公共屬性和方法。
在GOF的設計模式書上是這樣描述的：雖然在分析階段這種關系是適用的，但我們覺得它對於描述設計模式內的類關系來說顯得太抽象了，因為在設計階段關聯關系必須被映射為對象引用或指針。對象引用本身就是有向的，更適合表達我們所討論的那種關系。所以這種關系在設計的時候比較少用到，關聯一般都是有向的。
使用ROSE 生成的代碼是這樣的：

雙向關聯在代碼的表現為雙方都擁有對方的一個指針，當然也可以是引用或者是值。

單向關聯:

/**學生累*/
public class Student {
}

/**學校類*/
public class School {
    public Student tom;
}

C3->C4：表示相識關系，指C3知道C4，C3可以調用C4的公共屬性和方法。沒有生命期的依賴。一般是表示為一種引用。
生成代碼如下：

單向關聯的代碼就表現為C3有C4的指針，而C4對C3一無所知。

自身關聯（反身關聯）：
自己引用自己，帶着一個自己的引用。
代碼如下：

public class Node {
    //數據
    public int data;
    
    public Node next;
    public Node prev;
}

就是在自己的內部有着一個自身的引用。

2.2.2、聚合/組合

當類之間有整體-部分關系的時候，我們就可以使用組合或者聚合。

聚合：是一種弱偶合的關聯關系。

/**人*/
public class Person {
}

/**引擎*/
public class Engine {
}

/**車*/
public class Car {
    /**組合*/
    private Engine engine;
    public Car(Engine engine){
        this.engine=engine;
    }

    /**聚合*/
   public Person driver;
}

組合（也有人稱為包容）：一般是實心菱形加實線箭頭表示，如上圖所示，表示的是C8被C7包容，而且C8不能離開C7而獨立存在。但這是視問題域而定的，例如在關心汽車的領域里，輪胎是一定要組合在汽車類中的，因為它離開了汽車就沒有意義了。但是在賣輪胎的店鋪業務里，就算輪胎離開了汽車，它也是有意義的，這就可以用聚合了。在《敏捷開發》中還說到，A組合B，則A需要知道B的生存周期，即可能A負責生成或者釋放B，或者A通過某種途徑知道B的生成和釋放。

2.2.3、依賴

依賴是一種非常弱的關聯關系。

/**人*/
public class Person {
    /**吃食物*/
    public void eat(Food food){
        System.out.println("正在吃"+food.name);
    }
}

那依賴和聚合\組合、關聯等有什么不同呢？
關聯是類之間的一種關系，例如老師教學生，老公和老婆，水壺裝水等就是一種關系。這種關系是非常明顯的，在問題領域中通過分析直接就能得出。
依賴是一種弱關聯，只要一個類用到另一個類，但是和另一個類的關系不是太明顯的時候（可以說是“uses”了那個類），就可以把這種關系看成是依賴，依賴也可說是一種偶然的關系，而不是必然的關系，就是“我在某個方法中偶然用到了它，但在現實中我和它並沒多大關系”。例如我和錘子，我和錘子本來是沒關系的，但在有一次要釘釘子的時候，我用到了它，這就是一種依賴，依賴錘子完成釘釘子這件事情。

組合是一種整體-部分的關系，在問題域中這種關系很明顯，直接分析就可以得出的。例如輪胎是車的一部分，樹葉是樹的一部分，手腳是身體的一部分這種的關系，非常明顯的整體-部分關系。
上述的幾種關系（關聯、聚合/組合、依賴）在代碼中可能以指針、引用、值等的方式在另一個類中出現，不拘於形式，但在邏輯上他們就有以上的區別。
這里還要說明一下，所謂的這些關系只是在某個問題域才有效，離開了這個問題域，可能這些關系就不成立了，例如可能在某個問題域中，我是一個木匠，需要拿着錘子去干活，可能整個問題的描述就是我拿着錘子怎么釘桌子，釘椅子，釘櫃子；既然整個問題就是描述這個，我和錘子就不僅是偶然的依賴關系了，我和錘子的關系變得非常的緊密，可能就上升為組合關系（讓我突然想起武俠小說的劍不離身，劍亡人亡...）。這個例子可能有點荒謬，但也是為了說明一個道理，就是關系和類一樣，它們都是在一個問題領域中才成立的，離開了這個問題域，他們可能就不復存在了。

2.2.4、泛化（繼承）

泛化關系：如果兩個類存在泛化的關系時就使用，例如父和子，動物和老虎，植物和花等。
ROSE生成的代碼很簡單，如下：

/**學生累*/
public class Student extends Person {
}

在UML建模中，對類圖上出現元素的理解是至關重要的。開發者必須理解如何將類圖上出現的元素轉換到Java中。以java為代表結合網上的一些實例，下面是個人一些基本收集與總結：

 

基本元素符號：

1. 類（Classes）

類包含3個組成部分。第一個是Java中定義的類名。第二個是屬性（attributes）。第三個是該類提供的方法。

屬性和操作之前可附加一個可見性修飾符。加號（+）表示具有公共可見性。減號（-）表示私有可見性。#號表示受保護的可見性。省略這些修飾符表示具有package（包）級別的可見性。如果屬性或操作具有下划線，表明它是靜態的。在操作中，可同時列出它接受的參數，以及返回類型，如下圖所示：

2. 包（Package）

包是一種常規用途的組合機制。UML中的一個包直接對應於Java中的一個包。在Java中，一個包可能含有其他包、類或者同時含有這兩者。進行建模時，你通常擁有邏輯性的包，它主要用於對你的模型進行組織。你還會擁有物理性的包，它直接轉換成系統中的Java包。每個包的名稱對這個包進行了惟一性的標識。

3. 接口（Interface）

接口是一系列操作的集合，它指定了一個類所提供的服務。它直接對應於Java中的一個接口類型。接口既可用下面的那個圖標來表示（上面一個圓圈符號，圓圈符號下面是接口名，中間是直線，直線下面是方法名），也可由附加了<<interface>>的一個標准類來表示。通常，根據接口在類圖上的樣子，就能知道與其他類的關系。

關系：

1. 依賴（Dependency）

實體之間一個“使用”關系暗示一個實體的規范發生變化后，可能影響依賴於它的其他實例。更具體地說，它可轉換為對不在實例作用域內的一個類或對象的任何類型的引用。其中包括一個局部變量，對通過方法調用而獲得的一個對象的引用（如下例所示），或者對一個類的靜態方法的引用（同時不存在那個類的一個實例）。也可利用“依賴”來表示包和包之間的關系。由於包中含有類，所以你可根據那些包中的各個類之間的關系，表示出包和包的關系。

2. 關聯（Association）

實體之間的一個結構化關系表明對象是相互連接的。箭頭是可選的，它用於指定導航能力。如果沒有箭頭，暗示是一種雙向的導航能力。在Java中，關聯轉換為一個實例作用域的變量，就像圖E的“Java”區域所展示的代碼那樣。可為一個關聯附加其他修飾符。多重性（Multiplicity）修飾符暗示着實例之間的關系。在示范代碼中，Employee可以有0個或更多的TimeCard對象。但是，每個TimeCard只從屬於單獨一個Employee。

3. 聚合（Aggregation）

聚合是關聯的一種形式，代表兩個類之間的整體/局部關系。聚合暗示着整體在概念上處於比局部更高的一個級別，而關聯暗示兩個類在概念上位於相同的級別。聚合也轉換成Java中的一個實例作用域變量。

關聯和聚合的區別純粹是概念上的，而且嚴格反映在語義上。聚合還暗示着實例圖中不存在回路。換言之，只能是一種單向關系。

4. 組合（Composition）

合成是聚合的一種特殊形式，暗示“局部”在“整體”內部的生存期職責。合成也是非共享的。所以，雖然局部不一定要隨整體的銷毀而被銷毀，但整體要么負責保持局部的存活狀態，要么負責將其銷毀。

局部不可與其他整體共享。但是，整體可將所有權轉交給另一個對象，后者隨即將承擔生存期職責。Employee和TimeCard的關系或許更適合表示成“合成”，而不是表示成“關聯”。

5. 泛化（Generalization）

泛化表示一個更泛化的元素和一個更具體的元素之間的關系。泛化是用於對繼承進行建模的UML元素。在Java中，用extends關鍵字來直接表示這種關系。

6. 實現（Realization）

實例關系指定兩個實體之間的一個合同。換言之，一個實體定義一個合同，而另一個實體保證履行該合同。對Java應用程序進行建模時，實現關系可直接用implements關鍵字來表示。

引用地址：http://www.cnblogs.com/riky/archive/2007/04/07/704298.html

三、設計原則

2.1、單一職責原則（SRP）

一個類，只有一個引起它變化的原因。應該只有一個職責。每一個職責都是變化的一個軸線，如果一個類有一個以上的職責，這些職責就耦合在了一起。這會導致脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一起，會影響復用性。例如：要實現邏輯和界面的分離。

一個類只擔任一種角色。

 下面這個jsp頁面就不符合SRP原則，它要擔任展示UI與訪問數據庫兩個角色。分層是一種解決辦法。

<%@ page contentType="text/html; charset=gb2312" %>   
<%@ page language="java" %>   
<%@ page import="com.mysql.jdbc.Driver" %>   
<%@ page import="java.sql.*" %>   
<%   
//加載驅動程序   
String driverName="com.mysql.jdbc.Driver";   
//數據庫信息  
String userName="root";   
//密碼   
String userPasswd="123";   
//數據庫名   
String dbName="Student";   
//表名   
String tableName="stu_info";   
//將數據庫信息字符串連接成為一個完整的url（也可以直接寫成url，分開寫是明了可維護性強）   
  
String url="jdbc:mysql://localhost/"+dbName+"?user="+userName+"&password="+userPasswd;   
Class.forName("com.mysql.jdbc.Driver").newInstance();   
Connection conn=DriverManager.getConnection(url);   
Statement stmt = conn.createStatement();   
String sql="SELECT * FROM "+tableName;   
ResultSet rs = stmt.executeQuery(sql);   
out.print("id");   
out.print("|");   
out.print("name");   
out.print("|");   
out.print("phone");   
out.print("<br>");   
while(rs.next()) {   
out.print(rs.getString(1)+" ");   
out.print("|");   
out.print(rs.getString(2)+" ");   
out.print("|");   
out.print(rs.getString(3));   
out.print("<br>");   
}   
out.print("<br>");   
out.print("ok， Database Query Successd！");   
rs.close();   
stmt.close();   
conn.close();   
%>  

2.2、開閉原則（Open Close Principle OCP）

開閉原則就是說對擴展開放，對修改關閉。在程序需要進行拓展的時候，不能去修改原有的代碼，實現一個熱插拔的效果。所以一句話概括就是：為了使程序的擴展性好，易於維護和升級。想要達到這樣的效果，我們需要使用接口和抽象類，后面的具體設計中我們會提到這點。

美猴王說："'皇帝輪流做，明年到我家。'只教他搬出去，將天宮讓於我！"對於這項挑戰，太白金星給玉皇大帝提出的建議是："降一道招安聖旨，宣上界來…，一則不勞師動眾，二則收仙有道也。

不要隨意修改頂層接口，可以通過繼承或其它辦法擴展出新的內容。

功能實現應該對擴展開放，對修改關閉，應該通過擴展來實現（應對）變化，而不是通過修改已有的代碼來實現變化的內容。

參考

2.3、里氏代換原則（Liskov Substitution Principle LSP）

里氏代換原則(Liskov Substitution Principle LSP)面向對象設計的基本原則之一。 里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。 LSP是繼承復用的基石，只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。里氏代換原則是對“開-閉”原則的補充。實現“開-閉”原則的關鍵步驟就是抽象化。而基類與子類的繼承關系就是抽象化的具體實現，所以里氏代換原則是對實現抽象化的具體步驟的規范。老鼠的兒子會打洞。

        Person tom=new Student();
        Object mark=new Teacher();

子類可以覆蓋父類的抽象方法，但不能覆蓋非抽象方法。

如果需要覆蓋父類的非抽象方法，參數的類型必須要比父類的寬松，返回值類型必須要比父類嚴格。

子類可以擁有自己的成員方法。

在項目中，采用里氏替換原則時，盡量避免子類的“個性”，一旦子類有了“個性”，這個子類和父類之間的關系就難調和，把子類當做父類使用，子類的“個性”被抺殺了，把子類單獨作為一個業務來使用，則會讓代碼間的耦合關系變得撲朔迷離–缺乏類替換的標准。

2.4、依賴倒轉原則（Dependence Inversion Principle DIP）

所謂依賴倒置原則（Dependence Inversion Principle）就是要依賴於抽象，不要依賴於具體。簡單的說就是要求對抽象進行編程，不要對實現進行編程，這樣就降低了客戶與實現模塊間的耦合。
實現開閉原則的關鍵是抽象化，並且從抽象化導出具體化實現，如果說開閉原則是面向對象設計的目標的話，那么依賴倒轉原則就是面向對象設計的主要手段。 細節應該依賴抽象，抽象應該依賴抽象，抽象不應該依賴細節

/**人*/
public class Person {
    /**吃食物*/
    public void eat(Food food){  //依賴具體
        System.out.println("正在吃"+food.name);
        Person tom=new Student();
        Object mark=new Teacher();
    }

    //Student繼承Person
    //依賴抽象
    public void Show(Person person){
    }
    //依賴具體
    public void Hello(Student student){
    }
}

2.5、接口隔離原則（Interface Segregation Principle ISP）

這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。還是一個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是一個軟件的設計思想，從大型軟件架構出發，為了升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。

/**可飛的*/
interface IFlyable{
    public void fly();
}

/**下蛋*/
interface  ILayeggAble{
    public void Layegg();
}

interface  IBirdable{
    public void fly();
    public void Layegg();
}

IBirdable如果被超人（SuperMan）實現則除了要實現fly方法飛還要實現下蛋接方法，超人下蛋不太合適。

2.6、合成復用原則（Composite Reuse Principle）

合成復用原則就是指在一個新的對象里通過關聯關系（包括組合關系和聚合關系）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調用已有對象的方法達到復用其已有功能的目的。簡言之：要盡量使用組合/聚合關系，少用繼承。

2.7、迪米特法則（最少知道原則）（Demeter Principle）

為什么叫最少知道原則，就是說：一個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模塊相對獨立。也就是說一個軟件實體應當盡可能少的與其他實體發生相互作用。這樣，當一個模塊修改時，就會盡量少的影響其他的模塊，擴展會相對容易，這是對軟件實體之間通信的限制，它要求限制軟件實體之間通信的寬度和深度。

小結：

1、單一職責原則
二層含義，一是避免相同的職責分散到不同的類中，二是避免一個類承擔太多職責。減少類的耦合，提高類的復用性。

2、接口隔離原則

表明客戶端不應該被強迫實現一些他們不會使用的接口，應該把胖接口中額方法分組，然后用多個接口代替它，每個接口服務於一個子模塊。簡單說，就是使用多個專門的接口比使用單個接口好很多。

該原則觀點如下：
  a，一個類對另外一個類的依賴性應當是建立在最小的接口上

  b，客戶端程序不應該依賴它不需要的接口方法。

3、開放-關閉原則

open模塊的行為必須是開放的、支持擴展的，而不是僵化的。

closed在對模塊的功能進行擴展時，不應該影響或大規模影響已有的程序模塊。一句話概括：一個模塊在擴展性方面應該是開放的而在更改性方面應該是封閉的。

核心思想就是對抽象編程，而不對具體編程。

4、里氏替換原則

子類型必須能夠替換掉他們的父類型、並出現在父類能夠出現的任何地方。

主要針對繼承的設計原則

1，父類的方法都要在子類中實現或者重寫，並且派生類只實現其抽象類中生命的方法，而不應當給出多余的,方法定義或實現。
2，在客戶端程序中只應該使用父類對象而不應當直接使用子類對象，這樣可以實現運行期間綁定。

5、依賴倒置原則

上層模塊不應該依賴於下層模塊，他們共同依賴於一個抽象(父類不能依賴子類，他們都要依賴抽象類)
抽象不能依賴於具體，具體應該要依賴於抽象。

四、示例與資料

示例：https://coding.net/u/zhangguo5/p/DP01/git

視頻：https://www.bilibili.com/video/av15867320/

五、視頻與作業

5.1、作業

1、使用java代碼實現下圖，理解他們之間的關系

2、請記住類之間的關系

3、請記住5大設計原則並作簡單描述