一、三大特性
- 封裝
- 繼承
- 多態
二、類圖
- 泛化關系 (Generalization)
- 實現關系 (Realization)
- 聚合關系 (Aggregation)
- 組合關系 (Composition)
- 關聯關系 (Association)
- 依賴關系 (Dependency)
三、設計原則
- S.O.L.I.D
- 其他常見原則
參考資料

一、三大特性

封裝

利用抽象數據類型將數據和基于數據的操作封裝在一起，使其構成一個不可分割的獨立實體。數據被保護在抽象數據類型的內部，盡可能地隱藏內部的細節，只保留一些對外的接口使其與外部發生聯系。用戶無需關心對象內部的細節，但可以通過對象對外提供的接口來訪問該對象。

優點：

減少耦合：可以獨立地開發、測試、優化、使用、理解和修改
減輕維護的負擔：可以更容易被理解，并且在調試的時候可以不影響其他模塊
有效地調節性能：可以通過剖析來確定哪些模塊影響了系統的性能
提高軟件的可重用性
降低了構建大型系統的風險：即使整個系統不可用，但是這些獨立的模塊卻有可能是可用的

以下 Person 類封裝 name、gender、age 等屬性，外界只能通過 get() 方法獲取一個 Person 對象的 name 屬性和 gender 屬性，而無法獲取 age 屬性，但是 age 屬性可以供 work() 方法使用。

注意到 gender 屬性使用 int 數據類型進行存儲，封裝使得用戶注意不到這種實現細節。并且在需要修改 gender 屬性使用的數據類型時，也可以在不影響客戶端代碼的情況下進行。

public class Person {private String name;private int gender;private int age;public String getName() {return name;}public String getGender() {return gender == 0 ? "man" : "woman";}public void work() {if (18 <= age && age <= 50) {System.out.println(name + " is working very hard!");} else {System.out.println(name + " can't work any more!");}}
}

繼承

繼承實現了 IS-A 關系，例如 Cat 和 Animal 就是一種 IS-A 關系，因此 Cat 可以繼承自 Animal，從而獲得 Animal 非 private 的屬性和方法。

繼承應該遵循里氏替換原則，子類對象必須能夠替換掉所有父類對象。

Cat 可以當做 Animal 來使用，也就是說可以使用 Animal 引用 Cat 對象。父類引用指向子類對象稱為 向上轉型 。

Animal animal = new Cat();

多態

多態分為編譯時多態和運行時多態：

編譯時多態主要指方法的重載
運行時多態指程序中定義的對象引用所指向的具體類型在運行期間才確定

運行時多態有三個條件：

繼承
覆蓋（重寫）
向上轉型

下面的代碼中，樂器類（Instrument）有兩個子類：Wind 和 Percussion，它們都覆蓋了父類的 play() 方法，并且在 main() 方法中使用父類 Instrument 來引用 Wind 和 Percussion 對象。在 Instrument 引用調用 play() 方法時，會執行實際引用對象所在類的 play() 方法，而不是 Instrument 類的方法。

public class Instrument {public void play() {System.out.println("Instument is playing...");}
}

public class Wind extends Instrument {public void play() {System.out.println("Wind is playing...");}
}

public class Percussion extends Instrument {public void play() {System.out.println("Percussion is playing...");}
}

public class Music {public static void main(String[] args) {List<Instrument> instruments = new ArrayList<>();instruments.add(new Wind());instruments.add(new Percussion());for(Instrument instrument : instruments) {instrument.play();}}
}

Wind is playing...
Percussion is playing...

二、類圖

以下類圖使用 PlantUML 繪制，更多語法及使用請參考：http://plantuml.com/ 。

泛化關系 (Generalization)

用來描述繼承關系，在 Java 中使用 extends 關鍵字。

@startumltitle Generalizationclass Vihical
class Car
class TrunckVihical <|-- Car
Vihical <|-- Trunck@enduml

實現關系 (Realization)

用來實現一個接口，在 Java 中使用 implements 關鍵字。

@startumltitle Realizationinterface MoveBehavior
class Fly
class RunMoveBehavior <|.. Fly
MoveBehavior <|.. Run@enduml

聚合關系 (Aggregation)

表示整體由部分組成，但是整體和部分不是強依賴的，整體不存在了部分還是會存在。

@startumltitle Aggregationclass Computer
class Keyboard
class Mouse
class ScreenComputer o-- Keyboard
Computer o-- Mouse
Computer o-- Screen@enduml

組合關系 (Composition)

和聚合不同，組合中整體和部分是強依賴的，整體不存在了部分也不存在了。比如公司和部門，公司沒了部門就不存在了。但是公司和員工就屬于聚合關系了，因為公司沒了員工還在。

@startumltitle Compositionclass Company
class DepartmentA
class DepartmentBCompany *-- DepartmentA
Company *-- DepartmentB@enduml

關聯關系 (Association)

表示不同類對象之間有關聯，這是一種靜態關系，與運行過程的狀態無關，在最開始就可以確定。因此也可以用 1 對 1、多對 1、多對多這種關聯關系來表示。比如學生和學校就是一種關聯關系，一個學校可以有很多學生，但是一個學生只屬于一個學校，因此這是一種多對一的關系，在運行開始之前就可以確定。

@startumltitle Associationclass School
class StudentSchool "1" - "n" Student@enduml

依賴關系 (Dependency)

和關聯關系不同的是，依賴關系是在運行過程中起作用的。A 類和 B 類是依賴關系主要有三種形式：

A 類是 B 類方法的局部變量；
A 類是 B 類方法的參數；
A 類向 B 類發送消息，從而影響 B 類發生變化。

@startumltitle Dependencyclass Vihicle {move(MoveBehavior)
}interface MoveBehavior {move()
}note "MoveBehavior.move()" as NVihicle ..> MoveBehaviorVihicle .. N@enduml

三、設計原則

S.O.L.I.D

簡寫	全拼	中文翻譯
SRP	The Single Responsibility Principle	單一責任原則
OCP	The Open Closed Principle	開放封閉原則
LSP	The Liskov Substitution Principle	里氏替換原則
ISP	The Interface Segregation Principle	接口分離原則
DIP	The Dependency Inversion Principle	依賴倒置原則

1. 單一責任原則

修改一個類的原因應該只有一個。

換句話說就是讓一個類只負責一件事，當這個類需要做過多事情的時候，就需要分解這個類。

如果一個類承擔的職責過多，就等于把這些職責耦合在了一起，一個職責的變化可能會削弱這個類完成其它職責的能力。

2. 開放封閉原則

類應該對擴展開放，對修改關閉。

擴展就是添加新功能的意思，因此該原則要求在添加新功能時不需要修改代碼。

符合開閉原則最典型的設計模式是裝飾者模式，它可以動態地將責任附加到對象上，而不用去修改類的代碼。

3. 里氏替換原則

子類對象必須能夠替換掉所有父類對象。

繼承是一種 IS-A 關系，子類需要能夠當成父類來使用，并且需要比父類更特殊。

如果不滿足這個原則，那么各個子類的行為上就會有很大差異，增加繼承體系的復雜度。

4. 接口分離原則

不應該強迫客戶依賴于它們不用的方法。

因此使用多個專門的接口比使用單一的總接口要好。

5. 依賴倒置原則

高層模塊不應該依賴于低層模塊，二者都應該依賴于抽象；抽象不應該依賴于細節，細節應該依賴于抽象。

高層模塊包含一個應用程序中重要的策略選擇和業務模塊，如果高層模塊依賴于低層模塊，那么低層模塊的改動就會直接影響到高層模塊，從而迫使高層模塊也需要改動。

依賴于抽象意味著：

任何變量都不應該持有一個指向具體類的指針或者引用；
任何類都不應該從具體類派生；
任何方法都不應該覆寫它的任何基類中的已經實現的方法。

其他常見原則

除了上述的經典原則，在實際開發中還有下面這些常見的設計原則。

簡寫	全拼	中文翻譯
LOD	The Law of Demeter	迪米特法則
CRP	The Composite Reuse Principle	合成復用原則
CCP	The Common Closure Principle	共同封閉原則
SAP	The Stable Abstractions Principle	穩定抽象原則
SDP	The Stable Dependencies Principle	穩定依賴原則