面向對象六大原則

這篇文章主要講的是面向對象設計中，應該遵循的六大原則。隻有掌握了這些原則，才能更好的了解設計模式。

我們接下來要介紹以下6個内容。

• 單一職責原則——SRP
• 開閉原則——OCP
• 裡氏替換原則——LSP
• 依賴倒置原則——DIP
• 接口隔離原則——ISP
• 迪米特原則——LOD

0x01: 單一職責原則

單一職責原則的定義是就一個類而言，應該僅有一個引起他變化的原因。也就是說一個類應該隻負責一件事情。如果一個類負責了方法M1,方法M2兩個不同的事情，當M1方法發生變化的時候，我們需要修改這個類的M1方法，但是這個時候就有可能導緻M2方法不能工作。這個不是我們期待的，但是由于這種設計卻很有可能發生。是以這個時候，我們需要把M1方法，M2方法單獨分離成兩個類。讓每個類隻專心處理自己的方法。

單一職責原則的好處如下：

可以降低類的複雜度，一個類隻負責一項職責，這樣邏輯也簡單很多

提高類的可讀性，和系統的維護性，因為不會有其他奇怪的方法來幹擾我們了解這個類的含義

當發生變化的時候，能将變化的影響降到最小，因為隻會在這個類中做出修改。

0x02: 開閉原則

開閉原則和單一職責原則一樣，是非常基礎而且一般是常識的原則。開閉原則的定義是軟體中的對象(類，子產品，函數等)應該對于擴充是開放的，但是對于修改是關閉的。

當需求發生改變的時候，我們需要對代碼進行修改，這個時候我們應該盡量去擴充原來的代碼，而不是去修改原來的代碼，因為這樣可能會引起更多的問題。

這個準則和單一職責原則一樣，是一個大家都這樣去認為但是又沒規定具體該如何去做的一種原則。

開閉原則我們可以用一種方式來確定他，我們用抽象去建構架構，用實作擴充細節。這樣當發生修改的時候，我們就直接用抽象了派生一個具體類去實作修改。

0x03: 裡氏替換原則

裡氏替換原則是一個非常有用的一個概念。他的定義

如果對每一個類型為T1的對象o1,都有類型為T2的對象o2,使得以T1定義的所有程式P在所有對象o1都替換成o2的時候，程式P的行為都沒有發生變化，那麼類型T2是類型T1的子類型。

這樣說有點複雜，其實有一個簡單的定義

所有引用基類的地方必須能夠透明地使用其子類的對象。

裡氏替換原則通俗的去講就是：子類可以去擴充父類的功能，但是不能改變父類原有的功能。他包含以下幾層意思：

子類可以實作父類的抽象方法，但是不能覆寫父類的非抽象方法。

子類可以增加自己獨有的方法。

當子類的方法重載父類的方法時候，方法的形參要比父類的方法的輸入參數更加寬松。

當子類的方法實作父類的抽象方法時，方法的傳回值要比父類更嚴格。

裡氏替換原則之是以這樣要求是因為繼承有很多缺點，他雖然是複用代碼的一種方法，但同時繼承在一定程度上違反了封裝。父類的屬性和方法對子類都是透明的，子類可以随意修改父類的成員。這也導緻了，如果需求變更，子類對父類的方法進行一些複寫的時候，其他的子類無法正常工作。是以裡氏替換法則被提出來。

確定程式遵循裡氏替換原則可以要求我們的程式建立抽象，通過抽象去建立規範，然後用實作去擴充細節，這個是不是很耳熟，對，裡氏替換原則和開閉原則往往是互相依存的。

0x04: 依賴倒置原則

依賴倒置原則指的是一種特殊的解耦方式，使得高層次的子產品不應該依賴于低層次的子產品的實作細節的目的，依賴子產品被颠倒了。

這也是一個讓人難懂的定義，他可以簡單來說就是

高層子產品不應該依賴底層子產品，兩者都應該依賴其抽象

抽象不應該依賴細節

細節應該依賴抽象

在Java 中抽象指的是接口或者抽象類，兩者皆不能執行個體化。而細節就是實作類，也就是實作了接口或者繼承了抽象類的類。他是可以被執行個體化的。高層子產品指的是調用端，底層子產品是具體的實作類。在Java中，依賴倒置原則是指子產品間的依賴是通過抽象來發生的，實作類之間不發生直接的依賴關系，其依賴關系是通過接口是來實作的。這就是俗稱的面向接口程式設計。

下面有一個例子來講述這個問題。這個例子是勞工用錘子來修理東西。代碼如下：

public class Hammer {
    public String function(){
        return "用錘子修理東西";
    }
}

public class Worker {
    public void fix(Hammer hammer){
        System.out.println("勞工" + hammer.function());
    }


    public static void main(String[] args) {
        new Worker().fix(new Hammer());
    }
}
           

這個是一個很簡單的例子，但是如果我們要新增加一個功能，勞工用 螺絲刀來修理東西，在這個類，我們發現是很難做的。因為我們Worker類依賴于一個具體的實作類Hammer。是以我們用到面向接口程式設計的思想，改成如下的代碼：

public interface Tools {
    public String function();
}
           

然後我們的Worker是通過這個接口來于與其他細節類進行依賴。代碼如下：

public class Worker {
    public void fix(Tools tool){
        System.out.println("勞工" + tool.function());
    }


    public static void main(String[] args) {
        new Worker().fix(new Hammer());
        new Worker().fix(new Screwdriver());

    }
}
           

Hammer類與Screwdriver類實作這個接口

public class Hammer implements Tools{
    public String function(){
        return "用錘子修理東西";
    }
}

public class Screwdriver implements Tools{
    @Override
    public String function() {
        return "用螺絲刀修理東西";
    }
}
           

這樣，通過面向接口程式設計，我們的代碼就有了很高的擴充性，降低了代碼之間的耦合度，提高了系統的穩定性。

0x05: 接口隔離原則

接口隔離原則的定義是

用戶端不應該依賴他不需要的接口

換一種說法就是類間的依賴關系應該建立在最小的接口上。這樣說好像更難懂。我們通過一個例子來說明。我們知道在Java中一個具體類實作了一個接口，那必然就要實作接口中的所有方法。如果我們有一個類A和類B通過接口I來依賴，類B是對類A依賴的實作，這個接口I有5個方法。但是類A與類B隻通過方法1,2,3依賴，然後類C與類D通過接口I來依賴，類D是對類C依賴的實作但是他們卻是通過方法1,4,5依賴。那麼是必在實作接口的時候，類B就要有實作他不需要的方法4和方法5 而類D就要實作他不需要的方法2，和方法3。這簡直就是一個災難的設計。

是以我們需要對接口進行拆分，就是把接口分成滿足依賴關系的最小接口，類B與類D不需要去實作與他們無關接口方法。比如在這個例子中，我們可以把接口拆成3個，第一個是僅僅由方法1的接口，第二個接口是包含2,3方法的，第三個接口是包含4,5方法的。

這樣，我們的設計就滿足了接口隔離原則。

以上這些設計思想用英文的第一個字母可以組成SOLID ，滿足這個5個原則的程式也被稱為滿足了SOLID準則。

0x06：迪米特原則

迪米特原則也被稱為最小知識原則，他的定義

一個對象應該對其他對象保持最小的了解。

因為類與類之間的關系越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大，是以這也是我們提倡的軟體程式設計的總的原則：低耦合，高内聚。

迪米特法則還有一個更簡單的定義

隻與直接的朋友通信。首先來解釋一下什麼是直接的朋友：每個對象都會與其他對象有耦合關系，隻要兩個對象之間有耦合關系，我們就說這兩個對象之間是朋友關系。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變量、方法參數、方法傳回值中的類為直接的朋友，而出現在局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要作為局部變量的形式出現在類的内部。

這裡我們可以用一個現實生活中的例子來講解一下。比如我們需要一張CD,我們可能去音像店去問老闆有沒有我們需要的那張CD，老闆說現在沒有，等有的時候你們來拿就行了。在這裡我們不需要關心老闆是從哪裡，怎麼獲得的那張CD，我們隻和老闆（直接朋友）溝通，至于老闆從他的朋友那裡通過何種條件得到的CD，我們不關心，我們不和老闆的朋友（陌生人）進行通信，這個就是迪米特的一個應用。說白了，就是一種中介的方式。我們通過老闆這個中介來和真正提供CD的人發生聯系。

總結

到這裡，面向對象的六大原則，就寫完了。我們看出來，這些原則其實都是應對不斷改變的需求。每當需求變化的時候，我們利用這些原則來使我們的代碼改動量最小，而且所造成的影響也是最小的。但是我們在看這些原則的時候，我們會發現很多原則并沒有提供一種公式化的結論，而即使提供了公式化的結論的原則也隻是建議去這樣做。這是因為，這些設計原則本來就是從很多實際的代碼中提取出來的，他是一個經驗化的結論。怎麼去用它，用好它，就要依靠設計者的經驗。否則一味着去使用設計原則可能會使代碼出現過度設計的情況。大多數的原則都是通過提取出抽象和接口來實作，如果發生過度的設計，就會出現很多抽象類和接口，增加了系統的複雜度。讓本來很小的項目變得很龐大，當然這也是Java的特性（任何的小項目都會做成中型的項目）。

Java 的知識面非常廣，面試問的涉及也非常廣泛，重點包括：Java 基礎、Java 并發，JVM、MySQL、資料結構、算法、Spring、微服務、MQ 等等，涉及的知識點何其龐大，是以我們在複習的時候也往往無從下手，今天小編給大家帶來一套 Java 面試題，題庫非常全面，包括 Java 基礎、Java 集合、JVM、Java 并發、Spring全家桶、Redis、MySQL、Dubbo、Netty、MQ 等等，包含 Java 後端知識點 2000 +

資料擷取方式：關注公種浩：“程式員白楠楠”擷取上述資料