1. 程式人生 > >嘮嘮面試常問的,Java 面向物件設計的六大原則

嘮嘮面試常問的,Java 面向物件設計的六大原則

這篇文章主要講的是面向物件設計中,我們應該遵循的六大原則。只有掌握了這些原則,我們才能更好的理解設計模式。 我們接下來要介紹以下6個內容。

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

單一職責原則

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

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

可以降低類的複雜度,一個類只負責一項職責,這樣邏輯也簡單很多 提高類的可讀性,和系統的維護性,因為不會有其他奇怪的方法來干擾我們理解這個類的含義 當發生變化的時候,能將變化的影響降到最小,因為只會在這個類中做出修改。

開閉原則

開閉原則和單一職責原則一樣,是非常基礎而且一般是常識的原則。開閉原則的定義是軟體中的物件(類,模組,函式等)應該對於擴充套件是開放的,但是對於修改是關閉的。

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

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

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

里氏替換原則

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

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

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

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

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

  • 子類可以實現父類的抽象方法,但是不能覆蓋父類的非抽象方法。
  • 子類可以增加自己獨有的方法。
  • 當子類的方法過載父類的方法時候,方法的形參要比父類的方法的輸入引數更加寬鬆。
  • 當子類的方法實現父類的抽象方法時,方法的返回值要比父類更嚴格。

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

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

依賴倒置原則

依賴倒置原則指的是一種特殊的解耦方式,使得高層次的模組不應該依賴於低層次的模組的實現細節的目的,依賴模組被顛倒了。 這也是一個讓人難懂的定義,他可以簡單來說就是

高層模組不應該依賴底層模組,兩者都應該依賴其抽象 抽象不應該依賴細節 細節應該依賴抽象

在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 "用螺絲刀修理東西";
 }
}

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

介面隔離原則

介面隔離原則的定義是

客戶端不應該依賴他不需要的介面

換一種說法就是類間的依賴關係應該建立在最小的介面上。這樣說好像更難懂。我們通過一個例子來說明。我們知道在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準則。

迪米特原則

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

一個物件應該對其他物件保持最小的瞭解。

因為類與類之間的關係越密切,耦合度越大,當一個類發生改變時,對另一個類的影響也越大,所以這也是我們提倡的軟體程式設計的總的原則:低耦合,高內聚。 迪米特法則還有一個更簡單的定義

只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友:每個物件都會與其他物件有耦合關係,只要兩個物件之間有耦合關係,我們就說這兩個物件之間是朋友關係。耦合的方式很多,依賴、關聯、組合、聚合等。其中,我們稱出現成員變數、方法引數、方法返回值中的類為直接的朋友,而出現在區域性變數中的類則不是直接的朋友。也就是說,陌生的類最好不要作為區域性變數的形式出現在類的內部。

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

總結

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

歡迎工作一到五年的Java工程師朋友們加入Java程式設計師開發: 721575865

群內提供免費的Java架構學習資料(裡面有高可用、高併發、高效能及分散式、Jvm效能調優、Spring原始碼,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料)合理利用自己每一分每一秒的時間來學習提升自己,不要再用"沒有時間“來掩飾自己思想上的懶惰!趁年輕,使勁拼,給未來的