1、單一職責原則（Single-Responsibility Principle）
一個類應該只有一個能引起變化的原因，一個類的功能要單一，只做與它相關的事情
- 職責過多，可能引起它變化的原因就越多，這將導致職責依賴，相互之間就產生影響，從而大大損傷其內聚性和耦合度
1.1 優點
- 類的復雜性降低，實作什么職責都有清晰明確的定義
- 可讀性提高
- 可維護性提高
- 變更引起的風險降低，變更是必不可少的，如果介面的單一職責做得好，一個介面修改只對相應的實作類有影響，對其他的介面無影響，這對系統的擴展性、維護性都有非常大的幫助
1.2 示例
interface Human {
void cry();
void laugh();
void punch();
void kick();
}
- cry 與 laugh 屬于情緒一類的，punch 與 kick 屬于動作一類，雖然都同屬于 Human 介面，但兩個分類之間關聯并不大，還導致 Human 介面承擔的過多的職責
interface Mood{
void cry();
void laugh();
}
interface Act{
void punch();
void kick();
}
2、開放封閉原則（Open-Closed principle）
軟體物體（類，模塊，函式等）應該是可擴展的，而不可修改的，實作該原則的核心思想就是對抽象編程，而不對具體編程，因為抽象相對穩定
- 對擴展開放：有新的需求或變化時，可以對現有代碼進行擴展，以適應新的情況
- 通過面向物件的繼承和多型，使用重寫來改變固有行為，實作新的拓展方法，所以擴展是開放的
- 對修改封閉：類一旦設計完成，就可以獨立完成其作業，而不要對其進行任何的修改
- 讓類依賴于固定的抽象，所以修改就是封閉的
2.1 優點
- 有利于進行單元測驗
- 復用性提高
- 代碼可讀性高，可維護性提高
- 面向物件開發的要求
- 保持軟體內部的封裝體系穩定，不被需求的變化影響
2.2 示例
interface Phone {
void call();
}
class Nokia implements Phone {
@Override
public void call() {}
}
- 早期的諾基亞只有打電話的功能，隨著科技發展，又多了拍照、上網等功能
interface Phone {
void call();
}
class Nokia implements Phone {
@Override
public void call() {}
}
class NokiaWP8 extends Nokia {
@Override
public void call() {}
public void photograph() {}
public void surfing() {}
}
3、里氏替換原則（Liskov-Substitution Principle）
子類應當可以替換父類并出現在父類能夠出現的任何地方，這一思想體現為對繼承機制的約束規范，只有子類能夠替換父類時，才能保證系統在運行期內識別子類，這是保證繼承復用的基礎
- 這一約束反過來則是不成立的，子類可以替換基類，但是基類不一定能替換子類
- 子類可以擴展父類的功能，可以實作父類的抽象的方法，但不能覆寫改變父類的原有功能
該原則主要著眼于對抽象和多型建立在繼承的基礎上，因此只有遵循了里氏替換原則，才能保證繼承復用是可靠的，實作的方法是面向介面編程：將公共部分抽象為介面或抽象類，在子類中通過覆寫父類的方法實作新的方式支持同樣的職責
- 里氏替換原則是關于繼承機制的設計原則，違反了該原則就必然導致違反開放封閉原則， 里氏替換原則能夠保證系統具有良好的拓展性，同時實作基于多型的抽象機制，能夠減少代碼冗余，避免運行期的型別判斷
3.1 優點
- 代碼共享，減少創建類的作業量，每個子類都擁有父類的方法和屬性
- 提高代碼的重用性
- 提高代碼的可擴展性
- 提高專案的開放性
- 子類可以形似父類，但是又異于父類
3.2 示例
public class Demo {
public static void main(String[] args) {
Animal animal = new Animal();
animal.say(); // 嗷~
Animal human = new Human();
human.say(); // 艸
}
}
class Animal{
void say() {
System.out.println("嗷~");
}
}
class Human extends Animal {
@Override
void say() {
System.out.println("艸");
}
}
- 這個示例違反了里氏置換原則，子類方法覆寫了父類的方法
public class Demo {
public static void main(String[] args) {
Animal animal = new Animal();
animal.say(); // 嗷~
Animal human = new Human();
human.say(); // 嗷~
}
}
class Animal{
void say() {
System.out.println("嗷~");
}
}
class Human extends Animal {
@Override
void say() {
super.say();
}
}
4、依賴倒置原則（Dependecy-Inversion Principle）
高層模塊不依賴于底層模塊，二者都同依賴于抽象；抽象不依賴于具體，具體依賴于抽象
- 低層模塊：不可分割的原子邏輯，可能會根據業務邏輯經常變化
- 高層模塊：低層模塊的再組合，對低層模塊的抽象
依賴一定會存在于類與類、模塊與模塊之間，當兩個模塊之間存在緊密的耦合關系時，最好的方法就是分離介面和實作：在依賴之間定義一個抽象的介面使得高層模塊呼叫介面，而底層模塊實作介面的定義，以此來有效控制耦合關系，達到依賴于抽象的設計目標
- 抽象的穩定性決定了系統的穩定性，因為抽象是不變的，依賴于抽象是面向物件設計的精髓，也是依賴倒置原則的核心
4.1 優點
- 通過依賴于介面，隔離了具體實作類
- 低一層的變動并不會導致高一層的變動
- 提高了代碼的容錯性、擴展性和易于維護
4.2 示例
public class Demo {
public static void main(String[] args) {
User user = new User();
Phone phone = new Iphone();
user.usePhone(phone);
}
}
interface Phone {
void call();
}
interface Human {
void usePhone(Phone phone);
}
class Iphone implements Phone {
@Override
public void call() {
System.out.println("calling...");
}
}
class User extends Iphone implements Human {
@Override
public void usePhone(Phone phone) {
phone.call();
}
}
5、介面隔離原則（Interface-Segregation Principle）
客戶端不應該依賴它不需要的介面，一個類對另一個類的依賴應該建立在最小的介面上，介面應該是內聚的，應該避免大介面，介面有效地將細節和抽象隔離，強調了介面的單一性
- 單一職責原則要求是類和介面的職責單一，注重的職責，介面隔離原則是業務邏輯上的劃分，要求介面的方法盡量少
大介面存在明顯的弊端，必須得完全實作介面的所有方法、屬性等；而某些時候，并不需要所有的介面定義，而且對大介面的修改將導致一連串的程式需要修改，將大介面分解為多個特點的定制化方法，使得客戶端僅僅依賴于它們的實際呼叫的方法
分離的手段主要有兩種
- 委托分離，通過增加一個新的型別來委托客戶的請求，隔離客戶和介面的直接依賴，但是會增加系統的開銷
- 多重繼承分離，通過介面多繼承來實作客戶的需求，推薦
5.1 優點
- 避免介面污染
- 靈活性提高
- 提供定制服務
- 實作高內聚
5.2 示例
interface Behavior {
void eat();
void fly();
void speak();
}
class Bird implements Behavior {
@Override
public void eat() {}
@Override
public void fly() {}
@Override
public void speak() {}
}
class Human implements Behavior {
@Override
public void eat() {}
@Override
public void fly() {}
@Override
public void speak() {}
}
- 人類不需要 fly 方法，鳥類也不需要 speak 方法，但有一個共有的 eat 方法，可以將行為介面拆分為共有的行為介面、人類特定行為介面、鳥類特定行為介面
interface Beahvior {
void eat();
}
interface Behavior1 extends Beahvior {
void fly();
}
interface Behavior2 extends Beahvior {
void speak();
}
class Bird implements Behavior1 {
@Override
public void fly() {}
@Override
public void eat() {}
}
class Human implements Behavior2 {
@Override
public void eat() {}
@Override
public void speak() {}
}
6、最少知道原則 / 迪米特法則（Least Knowledge Principle）
一個物件應當對其他物件有盡可能少的了解，每個類盡量減少對其他類的依賴
該原則不希望類之間建立直接的接觸，如果真的有需要建立聯系，也希望能通過中間類來轉達，因此，迪米特原則有可能會造成系統中存在大量的中介類，這些類都是為了傳遞類之間的相互呼叫關系，在一定程度上增加了系統的復雜度
6.1 優點
- 減少物件之間的耦合性
6.2 示例
public class Demo {
public static void main(String[] args) {
Human human = new Human("Trump");
Phone phone = new Phone();
phone.call(new User(human));
}
}
class Phone {
void call(User user) {
user.callSomeone();
}
}
class Human {
String name;
public Human(String name) {
this.name = name;
}
}
class User {
private Human human;
public User(Human human) {
this.human = human;
}
void callSomeone() {
System.out.println("call: " + human.name);
}
}
7 、組合 / 聚合復用原則（Composite / Aggregate Reuse Principle）
在一個新的物件里面使用一些已有的物件，使之成為新物件的一部分，新物件通過向這些物件的委派達到復用已有功能的目的，盡量的使用合成和聚合，而不是繼承關系達到復用的目的
-
組合（Composition）表示一種強的擁有關系，體現了嚴格的部分和整體關系，部分和整體的生命周期一樣
-
聚合（Aggregation）表示一種弱的擁有關系，體現的是 A 物件可以包含 B 物件但 B 物件不是 A 物件的一部分
7.1 優點
- 新的實作較為容易，因為超類的大部分功能可通過繼承關系自動進入子類
- 修改或擴展繼承而來的實作較為容易
7.2 組合與繼承
| 組合關系 | 繼承關系 |
|---|---|
| 不破壞封裝，整體類與區域類之間松耦合，彼此相對獨立 | 破壞封裝，子類與父類之間緊密耦合，子類依賴于父類的實作，子類缺乏獨立性 |
| 具有較好的可擴展性 | 支持擴展，但是往往以增加系統結構的復雜度為代價 |
| 支持動態組合，在運行時，整體物件可以選擇不同型別的區域物件 | 不支持動態繼承，在運行時，子類無法選擇不同的父類 |
| 整體類可以對區域類進行包裝，封裝區域類的介面，提供新的介面 | 子類不能改變父類的介面 |
| 整體類不能自動獲得和區域類同樣的介面 | 子類能自動繼承父類的介面 |
| 創建整體類的物件時，需要創建所有區域類的物件 | 創建子類的物件時，無須創建父類的物件 |
- 建議在同樣可行的情況下，優先使用組合而不是繼承，因為組合更安全，更簡單，更靈活，更高效
- 只有當子類真正是超類的子型別時，才適合用繼承
7.3 示例
- 組合：Human 與 Air 是強擁有關系，人類不能離開空氣
class Human {
}
class Air {
private Human human;
public Air() {
human = new Human();
}
}
- 聚合：Phone 與 Human 是弱擁有關系，人類可以不用手機
class Phone {
}
class Human {
private Phone phone;
public Human() {
phone = new Phone();
}
}
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/68303.html
標籤：Java