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

時間 2019-12-08

標籤設計模式學習總結原則 uml 統一建模語言简体版

原文原文鏈接

1、概要

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

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

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

1.一、設計模式定義

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

1.二、設計模式分類

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

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

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

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

1.三、設計模式書籍

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

大話設計模式jsp

2、UML統一建模語言

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

2.一、UML分類

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

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

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

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

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

對象圖：是類圖的實例

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

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

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

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

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

合做圖：描述對象之間的協助關係

5.實現圖：

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

十種模型圖定義：

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

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

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

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

2.二、類圖

建模工具：Rose

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

2.2.一、關聯

雙向關聯：
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.二、聚合/組合

當類之間有總體-部分關係的時候，咱們就可使用組合或者聚合。

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

/**人*/
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.三、依賴

依賴是一種很是弱的關聯關係。

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

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

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

2.2.四、泛化（繼承）

泛化關係：若是兩個類存在泛化的關係時就使用，例如父和子，動物和老虎，植物和花等。
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

3、設計原則

2.一、單一職責原則（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.二、開閉原則（Open Close Principle OCP）

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

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

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

2.三、里氏代換原則（Liskov Substitution Principle LSP）

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

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

2.四、依賴倒轉原則（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.五、接口隔離原則（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.六、合成複用原則（Composite Reuse Principle）

合成複用原則就是指在一個新的對象裏經過關聯關係（包括組合關係和聚合關係）來使用一些已有的對象，使之成爲新對象的一部分；新對象經過委派調用已有對象的方法達到複用其已有功能的目的。簡言之：要儘可能使用組合/聚合關係，少用繼承。

2.七、迪米特法則（最少知道原則）（Demeter Principle）

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