面向物件設計原則---支援可維護性複用

1.單一職責原則：一個物件應該只包含單一的職責，並且該職責被完整地封裝在一個類中（就一個類而言，應該僅有一個引起它變化的原因）

2.開閉原則：軟體實體應當對擴充套件開放，對修改關閉

• 軟體實體：可以是一個軟體模組、一個由多個類組成的區域性結構或一個獨立的類
• 拓展：軟體實體應儘量在不修改原有程式碼的情況下進行擴充套件

3.里氏代換原則：所有引用基類的地方必須能透明地使用其子類的物件

• 將一個基類物件替換成它的子類物件，程式將不會產生任何錯誤和異常
• 儘量使用基類型別來對物件進行定義

4.依賴倒轉原則：高層模組不應該依賴低層模組，它們都應該依賴抽象。抽象不應該依賴於細節，細節應該依賴於抽象

• 要針對介面程式設計，不要針對實現程式設計
• 儘量引用層次高的抽象層類
• 在程式中儘量使用抽象層進行程式設計，而將具體類寫在配置檔案中
• 依賴注入
  • 構造注入
  • 設值注入（Setter注入）
  • 介面注入

5.介面隔離原則：客戶端不應該依賴那些它不需要的介面

• 分割大介面為細小的介面
• 客戶端僅需知道與之相關的方法
• 每一個介面應該承擔一種相對獨立的角色
• 介面定義
  • 一個型別所提供的所有方法特徵的集合；代表一個角色
  • 狹義的特定語言的介面；定製服務

6.合成複用原則：優先使用物件組合，而不是繼承來達到複用的目的

• 關聯關係使用已有物件使之成為新物件的一部分
• 委派已有物件的方法
• 少用繼承，多用組合/聚合
  • 繼承缺點太大：三大缺點
    • 會繼承父類中不需要的方法
    • 要繼承的類是final類，無法繼承
    • 修改不方便

P.S.

1.配置檔案+反射：教材49頁，自己看書

2.考題

• 結合某設計模式談談對某設計原則的理解（結合類圖和程式碼）
• 某設計方案可能違背哪些設計原則
• 設計模式的英文定義

3.開閉原則是目標，里氏替換原則是基礎，依賴倒置原則是手段

4.依賴倒置原則中父類儘可能要宣告子類中的方法

7.迪米特法則：一個軟體實體應當儘可能少地與其他實體發生相互作用

• 儘量減少物件之間的互動
• 引入一個合理的“第三者”來降低現有物件之間的耦合度
• 舉例：net->star(QQ聊天群)

設計模式

一、簡單工廠模式（靜態工廠方法模式）

• 定義一個工廠類，他可以根據引數的不同返回不同的類的例項，被建立的例項通常都具有相同的父類。

1.結構

• Factory（工廠角色）：工廠類，負責實現建立所有產品例項的內部邏輯。提供靜態工廠方法factoryMethod()，返回抽象產品型別
• Product（抽象產品角色）：所有物件的父類，封裝公有方法。
• ConcreteProduct（具體產品角色）：工廠建立的目標，需要實現抽象方法

2.關於建立物件與使用物件

• new
• 反射機制reflection
• 克隆方法clone/copy
• Factory
• 反序列化

P.S.

1.工廠模式中工廠的靜態方法

• 好處：可以直接使用類名呼叫
• 缺點：不支援多型

2.繼承結構->等級結構（名字替換）

3.增加新產品的時候，需要修改工廠原始碼，違背的開閉原則，同時增加工廠職責，違背單一職責原則

4.解析XML檔案

• DOM：存入記憶體，獲取節點
• SAX：逐行讀取檔案，用於檔案過大無法存入記憶體時

二、工廠方法模式

1.定義：定義一個用於建立物件的介面，但是讓子類決定將哪一個類例項化。工廠方法模式讓一個類的例項化延遲到其子類

2.結構

• Product：抽象產品
• ConcreteProduct：具體產品
• Factory：抽象工廠
• ConcreteFactory：具體工廠

3.反射機制與配置檔案

• 反射：程式在執行時獲取已知名稱的類或已有物件的相關資訊

  Class c=Class.forName("Class.name");
  Object obj=c.newInstance();
  return obj;
  

• 配置檔案

4.工廠方法的過載

• 新增引數，構造物件
• 在介面中過載方法，具體類中實現

5.工廠方法的隱藏

• 不建議使用，使得程式碼變得難以理解

6.優點+缺點+適用環境：P54

三、抽象工廠模式

1.產品等級結構：產品的繼承結構，抽象電視機與具體品牌的電視機

2.產品族：同一工廠的一組產品

3.定義：提供一個建立一系列相關或相互依賴物件的介面，而無需指定它們具體的類

4.結構：至少需要十個類

• AbstractFactory：抽象工廠
• ConcreteFactory：具體工廠
• AbstractProduct：抽象產品
• ConcreteProduct：具體產品

5.開閉原則的傾斜性

• 增加產品族時：符合開閉原則
• 增加產品等級結構時：不符合開閉原則

6.優點+缺點+適用模式：P68

三、原型模式

1.定義：使用原型例項指定待建立物件的型別，且通過複製這個原型來建立新的物件

2.三個角色

• Prototype（抽象原型類）：宣告克隆方法的介面，具體原型類的公共父類
• ConcretePrototype（具體原型類）：實現clone方法
• Client（客戶類）

3.淺clone與深clone：是否複製包含在原型物件中引用型別的成員變數

• 淺clone不復制，深clone複製

4.原型模式實現

• 通用實現方法：在clone方法中例項化一個自身型別相同的物件並且將其返回，同時將相關引數傳入新建立的物件中，保證成員變數相同
  • 對於引用型別的物件，使用賦值來實現複製，是淺clone
  • 使用建立一個全新的成員物件來實現複製，是深clone
• Java語言中的clone()方法和Cloneable介面
  • Java中clone方法滿足以下幾點
    • x.clone()!=x
    • x.clone().getClass()==x.getClass()
    • 若equals()方法定義恰當，x.clone.equals(x)

5.深clone解決方案

• 通過序列化，將物件寫到流中
• 需要實現Serializable介面

6.原型管理器

• 將多個原型物件儲存在一個集合中供客戶端使用，專門負責克隆物件的工廠

7.優點+缺點+使用環境：P102

四、單例模式

1.定義：確保一個類只有一個例項，並提供一個全域性訪問點來訪問這個唯一例項

2.結構：只包含一個單例角色Singleton，一個靜態方法getInstance()獲取唯一例項

3.實現：

• 存在一個靜態成員變數和靜態公有的工廠方法，工廠方法負責檢驗例項的存在並例項化自己，儲存在靜態成員變數中，確保只有一個例項被建立
• 注意
  • 建構函式為private
  • 提供一個型別為自身的靜態私有成員變數
  • 提供一個公有的靜態工廠方法

4.存在的問題：在多執行緒下可能導致例項不唯一（某個執行緒建立到一半，另一個執行緒也開始建立）

5.解決方案

• 餓漢式單例：在定義靜態變數的時候例項化單例類
  • 類被載入的時候，成員變數被初始化，唯一例項被建立
  • 優點：不需要考慮執行緒安全
  • 缺點：類載入的時候耗費時間長；這個例項及時不被使用，也會被建立並一直存在，佔用記憶體
• 懶漢式單例：在第一次被引用的時候將自己例項化（延遲載入）
  • 實現一：使用synchronized關鍵字對getInstance()方法上鎖（高併發下會導致系統性能降低）
  • 實現二：使用synchronized對建立例項的程式碼上鎖（相當於沒鎖）
  • 實現三：雙重檢查鎖定，對建立例項程式碼鎖定的同時，再加一行檢查程式碼（需要在靜態成員變數的前面加上volatile關鍵詞，取消虛擬機器對於程式碼的優化--重複檢查程式碼）
• Java中--靜態內部類IoDH：在單例類中新增一個靜態內部類
  • Java中靜態內部類的靜態物件載入時，Java虛擬機器會保證執行緒安全
  • 類載入時不會分配記憶體

6.優點+缺點+適用環境：P115

五、介面卡模式

1.定義：將一個類的介面轉換成客戶希望的另一個介面，介面卡模式讓那些介面不相容的類可以一起工作

2.結構

• Target-目標抽象類：客戶所需的介面
• Adapter-介面卡類：轉換器，產生聯絡
• Adaptee-適配者類：希望使用的介面

3.實現

• 類介面卡：介面卡實現Target介面，與適配者是繼承關係
• 物件介面卡：介面卡繼承Target介面，與適配者是關聯關係

4.預設介面卡模式

• 定義：當不需要實現一個介面中提供的所有方法時，可先設計一個抽象類實現該介面，併為介面中的每個方法提供一個預設實現（空方法），那麼該抽象類的子類可以選擇性的覆蓋父類的某些方法來實現需求。

• 適用於不想使用一個介面中所有方法的情況，又稱為單介面介面卡模式

• 結構：

  • ServiceInterface-適配者介面：介面，有大量方法
  • AbstractServiceClass-預設介面卡類：使用空方法實現
  • ConcreteServiceClass-具體業務類：子類，選擇覆蓋方法

5.雙向介面卡：Target和Adaptee可以互換角色

6.優點+缺點+適用環境：P129

P.S.判斷類模式和物件模式：關聯關係還是繼承關係

六、橋接模式（毛筆和蠟筆）

1.定義：將抽象部分（粒度大）與他的實現部分（粒度小）解耦，使得兩者都能夠獨立變化

2.結構：

• Abstraction-抽象類：
• RefinedAbstraction-擴充抽象類：
• Implementor-實現類介面：
• ConcreteImplementor-具體實現類：

3.實現：毛筆和蠟筆

4.橋接模式和介面卡模式的聯用

5.優點+缺點+適用環境：P144

七、組合模式（檔案與資料夾）

1.定義：組合多個物件形成樹形結構以表示具有部分-整體關係的層次結構。組合模式讓客戶端可以統一對待單個物件和組合物件

2.結構

• Component-抽象構件：介面或者抽象類
• Leaf-葉子構件：相當於檔案
• Composite-容器構件：相當於資料夾

3.實現

• 透明組合模式：Component中宣告所有管理成員物件的方法，不安全（檔案不能擁有資料夾的方法）
• 安全組合模式：Component中不宣告管理成員物件的方法，在Composite中宣告並實現

4.優點+缺點+適用環境：P158

八、外觀模式（茶館喝茶）

1.定義：為子系統中的一組介面提供一個統一的入口。外觀模式定義了一個高層介面，這個介面使得這一子系統更加容易被使用。（構建了一個茶館服務員）

2.結構

• Facade-外觀角色：茶館服務員
• SubSystem-子系統角色：需要的茶具，開水之類

3.實現

• 普通外觀模式在實現過程中由於沒有抽象層，在需要呼叫新的子系統的時候，需要修改原始碼，違背開閉原則
• 解決---抽象外觀類
• 可以與單例模式聯用：控制系統資源

4.優點+缺點+適用環境：P185

九、代理模式（代購）

1.定義：給某一個物件提供一個代理或者佔位符，並由代理物件來控制對源物件的訪問

2.結構

• Subject-抽象主題角色：真實主題和代理主題的共同介面，Client對於它進行程式設計，代購行業
• Proxy-代理主題角色：代購人
• RealSubject-真實主題角色：代購商品

3.實現

• 遠端代理：為一個位於不同地址空間中的物件提供一個本地的代理（大使）
• 虛擬代理：使用資源消耗消耗相對較小的物件表示資源消耗較大的物件（桌面快捷方式）
• 保護代理：控制對一個物件的訪問，提供不同級別的使用使用許可權
• 緩衝代理：為某一個目標操作的結果提供臨時的儲存空間，以便多個客戶端可以共享這些結果（記憶體->硬碟 空間換時間）
• 智慧引用代理：提供一些額外的操作
• Java動態代理：在系統執行時根據需要動態建立代理類

4.優點+缺點+適用環境：P217

十、裝飾模式

1.定義：動態的給一個物件增加一些額外的職責，就擴充套件功能而言，裝飾模式提供了一種比較用子類更加靈活的代替方案

2.例項：awt中的JList與JTable沒有滾動條，所以需要作為引數傳遞給JScrollPane建構函式，來實現滾動條的效果

3.結構

• Component-抽象構件：共同父類
• ConcreteComponent-具體構件：需要使用的構件
• Decorator-抽象裝飾類：裝飾類的抽象層
• ConcreteDecorator-具體裝飾類：負責給構件新增新的職責

十一、職責鏈模式（向學校請假）

1.定義：避免將一個請求的傳送者與接受者耦合在一起，讓多個物件獨有機會處理請求。將接收請求的物件連線成一條鏈，並且沿著這條鏈傳遞請求，直到有一個物件能夠處理它為止

2.結構

• Handler-抽象處理者：處理者的抽象層，面向該類程式設計，定義一個抽象處理者型別的物件，宣告處理方法
• ConcreteHandler-具體處理者：實現處理方法

3.實現

• 純職責鏈模式：每個請求一定被處理，且只被一個處理者處理
• 不純職責鏈模式：每個處理者可以只處理請求的一部分，請求也可以不被處理
• 許可權小的處理者要在鏈的前面
• 鏈在客戶端中定義----建鏈

4.優點+缺點+適用環境：P233

十二、命令模式（開關）

1.定義：將一個請求封裝為有一個物件，從而可用不同的請求對客戶進行引數化，對請求排隊或者記錄請求日誌，以及支援可撤銷的操作

2.結構

• Command-抽象命令類：宣告execute()方法，可用呼叫請求接收者的方法
• ConcreteCommand-具體命令類：實現方法，呼叫具體請求接收者
• Invoker-呼叫者：請求傳送者
• Receiver-接收者：執行與請求相關的操作

3.實現

• 命令佇列
• 記錄請求日誌
• 撤銷操作
• 巨集命令

十三、觀察者模式

1.定義：定義物件之間的一種一對多的依賴關係，使得每當一個物件狀態發生改變時其相關依賴物件皆得到通知並被自動更新

2.結構：

• Subject-目標：被觀察的物件
• ConcreteSubject-具體目標：
• Observer-觀察者：觀察目標的改變作出反應
• ConcreteObserver-具體觀察者：

3.實現

4.優點、缺點、使用環境

十四、模板方法模式---類行為型模式（流程）

1.定義：定義一個操作中演算法的框架，而將一些步驟延遲到子類中。模板方法模式使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟

2.結構：

• AbstractClass-抽象類：定義一系列基本操作、步驟，實現相同方法
• ConcreteClass-具體子類：特定實現不同的步驟

3.實現

• 模板方法：組合一系列步驟
• 基本方法：實現各個步驟
  • 抽象方法
  • 具體方法
  • 鉤子方法：一般返回bool型別，判斷是否執行某個步驟

十五、策略模式

1.定義：定義一系列演算法，將每一個演算法封裝起來，並讓他們可以相互替換。策略模式讓演算法可以獨立於使用它的客戶而變化

2.結構：

• Context-環境類：使用演算法的角色
• Strategy-抽象策略類：宣告演算法
• ConcreteStrategy-具體策略類：實現演算法