第2節 面向對象設計原則

一、面向對象設計

變化是複用的天敵，OOP設計的最大優勢在於抵禦變化！

二、重新認識面向對象

1. 理解隔離化：宏觀來講，OOP方式能夠將變化所帶來的影響減爲最小;
2. 各司其職：微觀上看，OOP更強調各個類的職責，由於需求的變化導致新增類型不改變原來的實現
3. 對象是什麼：

• 語言層面：封裝了代碼和數據
• 規格層面：對象是一系列可被使用的公共接口
• 概念層面：對象是擁有某些責任或功能的抽象

三、面向對象設計原則

1. 依賴倒置原則(DIP) 非常重要，幾乎貫穿所有設計模式

1.1  高層模塊(穩定)應該應依賴底層實現(變化)，二者都應該依賴於抽象;
1.2  抽象不應該依賴細節實現的變化，實現細節應該依賴於抽象;

2. 開放封閉原則(OCP)

2.1  對擴展開發，對更改封閉
2.2  類模塊應該是可擴展的，但是不可修改;

3. 單一職責原則(SRP)

3.1 一個類應該僅有一個引起變化的原因;
3.2 變化的方向隱含着類的責任;                   *** 單個類不能太臃腫，這就隱含着多責

4. Liskov替換原則(LSP)

4.1  子類必須能夠替代他們的基類 ：父類能做的，子類都可實現
4.2  繼承表達類型抽象：如果父類有很多方法子類沒用，說明是組合關係而非繼承關係

5. 接口隔離原則(ISP)

5.1  不應該強迫用戶依賴不用的方法;
5.2  接口應該小而完備：子類用則protected，只自己用則private，必要時才使用public

6. 有限使用對象組合而非繼承

6.1  類繼承通常爲"白箱複用"，對象組合爲"黑箱複用";
6.2  繼承在某種程度上破壞了封裝性，子類父類耦合度增加;
6.3  對象組合則要求對象具有良好的接口，耦合度低;

7. 封裝變化原則

7.1  使用封裝來創建對象的分階層，設計者可以在分階層一次進行修改，而不影響另一次

8. 面向接口編程而非面向實現編程

8.1  不將類型變量聲明爲具體類，而是某個接口;
8.2  客戶程序無需獲知對象的具體類型，而需知道對象接口;
8.3  減少系統中部分依賴關係，實現"高內聚、低耦合"的類型設計方案;

四、將設計原則提升爲設計經驗

1. 設計習語：描述與特定編程語言相關的底層模式，技巧和慣用法;
2. 設計模式：主要描述類與相互通信對象之間的組織關係，包括他們的角色、職責、寫作方式等方面；
3. 架構模式：描述系統中與基本結構組織關係密切的高層模式，包括子系統劃分、職責，一級如何組織他們之間的關係規則;

#include <stdio.h>
int main()
{
    // some codes
	return 0;
}