清掃車-全自動掃地
- 繼承：繼承自拖拉機，實現了掃地接口(介面)
- 封裝：要需知道如何運作、開動即可
- 多態：平時掃地，天然當風扇
- 多線程：10把掃把協同工作
- 低耦合：掃把可以更換為拖把
- 組件化：每個配件都可以替換
- 代碼托管：無需管理垃圾，掃至路邊即可
什麼是接口(介面)?
- 接口(介面)與抽象類類似，僅作功能聲明，不做程式碼實現的語法結構
只需把 class 關鍵字 換成 interface關鍵字
1
2
3
public interface ICalculator {
int Calculate();
}
為什麼需要接口(介面)?
- 根源上解耦，使系統之間的耦合減到最小，甚至耦合為零
舉例
「訂單處理系統」有一個「價格計算系統」，如果「價格計算系統」發生了變化，它一定會影響到「訂單處理系統」。
而訂單的變化又會反映到軟體中的其他系統，造成全局性的改變。
可以說，現在的「訂單處理系統」和「價格計算系統」是一個緊耦合的狀態。
1
2
OrderPressor --> PriceCalculator
訂單處理系統 依賴於 價格計算系統
所以，對於這樣的依賴關係，我們可以選擇使用 interface 來給這個給這個系統解耦。
1
2
OrderPressor --> IPriceCalculator
訂單處理系統 依賴於 價格計算接口(介面)
使用「價格計算接口(介面)」來代替之前的「價格系統」，我們的訂單系統則會從依賴一個類，轉換為依賴一個接口(介面)。
而這個接口(介面)，它只是一個簡單的定義，簡單的聲明，不是完整的class，不包含任何的業務邏輯，沒有程式碼的實現。
所以對於這個「價格計算接口(介面)」的實現，完全可以放在獨立的 class 中去處理。
比如說，現在「雙11」我們需要打折，所以計算系統為「雙11價格計算系統」，到了618，我們就可以切換為「618價格計算系統」，而平日裡，正常價格的時候，使用「正常價格計算系統」
1
2
OrderPressor --> IPriceCalculator
訂單處理系統 依賴於 價格計算接口(介面)
1
2
3
IPriceCalculator --> Price_1111 (雙11價格計算系統)
價格計算接口(介面) --> Price_618 (618價格計算系統)
--> PriceNormal (正常價格計算系統)
所以對訂單來說，整一個價格系統都是黑盒子，訂單系統只需要知道什麼時候調用這個價格系統就可以了。
而至於這個價格系統，底層邏輯是來自「雙11」、還是「618」、還是「平日的價格」，對訂單系統來說，這都不重要，他不知道，也不需要知道這個價格的具體計算過程。
所以通過接口(介面)，我們便可以順利的使「訂單系統」和「價格系統」形成一個鬆耦合的狀態。
接口(介面)是面向對象(物件導向)思想最重要的環節，而實際工作，我們經常需要先定義出兩個系統之間的接口(介面)，再各自開發這種預先定義接口(介面)的開發模式，我們就叫它面向接口編程。