SOLID原則的堅實指南| Baeldung

Windows · 發表 2019-02-06 21:02:00

摘要：在本教程中，我們將討論面向物件設計的SOLID原則。首先，我們將首先探討它們出現的原因以及為什麼在設計軟體時應該考慮它們。然後，我們將概述每個原則以及一些示例程式碼以強調這一點。 SOLID原則的原因 SOLID原則首先由Robert C. Martin在200...

在本教程中，我們將討論面向物件設計的SOLID原則。

首先，我們將首先探討它們出現的原因以及為什麼在設計軟體時應該考慮它們。然後，我們將概述每個原則以及一些示例程式碼以強調這一點。

SOLID原則的原因

SOLID原則首先由Robert C. Martin在2000年的論文“設計原則和設計模式”中概念化。這些概念後來由Michael Feathers構建，他們向我們介紹了SOLID的首字母縮略詞。在過去的20年中，這5個原則徹底改變了面向物件程式設計的世界，改變了我們編寫軟體的方式。

那麼，什麼是SOLID以及它如何幫助我們編寫更好的程式碼？簡而言之，Martin和Feathers的設計原則鼓勵我們建立更易於維護，易懂且靈活的軟體。因此，隨著我們的應用程式規模不斷擴大，我們可以降低其複雜性，併為您節省更多的麻煩！

以下5個概念構成了我們的SOLID原則：

S ingle Responsibility單一職責
O pen/Closed開閉原則
L iskov Substitution
I nterface Segregation介面分離
D ependency Injection依賴注射

雖然其中一些詞聽起來令人生畏，但可以通過一些簡單的程式碼示例輕鬆理解它們。在接下來的部分中，我們將深入探討每個原則的含義，以及一個快速的Java示例來說明每個原則。

1. 單一責任

讓我們用單一的責任原則來解決問題。正如我們所預料的那樣，這個原則規定一個類應該只有一個責任。此外，它只應該有一個改變的理由。

這個原則如何幫助我們構建更好的軟體？讓我們看看它的一些好處：

測試 - 具有一個職責的類將具有少得多的測試用例
較低的耦合 - 單個類中較少的功能將具有較少的依賴性
組織 - 較小，組織良好的類比單片類更容易搜尋

舉一個例如一個類來代表一本簡單的書：

<b>public</b> <b>class</b> Book {
 
<b>private</b> String name;
<b>private</b> String author;
<b>private</b> String text;
 
<font><i>//constructor, getters and setters</i></font><font>
}
</font>

在此程式碼中，我們儲存與Book例項關聯的名稱，作者和文字。

現在讓我們新增幾種查詢文字的方法：

<b>public</b> <b>class</b> Book {
 
<b>private</b> String name;
<b>private</b> String author;
<b>private</b> String text;
 
<font><i>//constructor, getters and setters</i></font><font>
 
</font><font><i>// methods that directly relate to the book properties</i></font><font>
<b>public</b> String replaceWordInText(String word){
<b>return</b> text.replaceAll(word, text);
}
 
<b>public</b> <b>boolean</b> isWordInText(String word){
<b>return</b> text.contains(word);
}
}
</font>

現在，我們的Book 類運作良好，我們可以在應用程式中儲存儘可能多的書籍。但是，如果我們無法將文字輸出到控制檯並閱讀它，那麼儲存資訊有什麼用？

新增列印方法：

<b>public</b> <b>class</b> Book {
<font><i>//...</i></font><font>
 
<b>void</b> printTextToConsole(){
</font><font><i>// our code for formatting and printing the text</i></font><font>
}
}
</font>

但是，此程式碼違反了我們之前概述的單一責任原則。為了修復我們的混亂，我們應該實現一個單獨的類，只關注列印我們的文字：

<b>public</b> <b>class</b> BookPrinter {
 
<font><i>// methods for outputting text</i></font><font>
<b>void</b> printTextToConsole(String text){
</font><font><i>//our code for formatting and printing the text</i></font><font>
}
 
<b>void</b> printTextToAnotherMedium(String text){
</font><font><i>// code for writing to any other location..</i></font><font>
}
}
</font>

真棒。我們不僅開發了一個新類來減輕 Book 的列印職責，而且還可以利用我們的 BookPrinter 類將文字傳送到其他媒體。

無論是電子郵件，日誌記錄還是其他任何內容，我們都有一個專門針對這一問題的類。

2. 開閉原則

類應該是可以擴充套件的，但是對修改是關閉，我們應該停止修改現有程式碼，否則會在經過測試的應用程式中引發潛在的新錯誤。當然，規則的一個例外是：修復現有程式碼中的錯誤。

讓我們通過快速程式碼示例進一步探索這個概念，作為新專案的一部分，想象一下我們已經實現了一個吉他類。

<b>public</b> <b>class</b> Guitar {
 
<b>private</b> String make;
<b>private</b> String model;
<b>private</b> <b>int</b> volume;
 
<font><i>//Constructors, getters & setters</i></font><font>
}
</font>

我們推出這個應用程式，每個人都喜歡它。然而，幾個月後，我們認為吉他有點無聊，可以用一個很棒的火焰模式讓它看起來更“搖滾”。

在這一點上，可能很容易開啟 Guitar 類並新增一個火焰模式 - 但是誰知道在我們的應用程式中可能會出現什麼錯誤。

相反，讓我們堅持開放式原則並簡單地擴充套件我們的吉他類(banq注：擴充套件類不代表一定要繼承，可以使用組合方式)：

<b>public</b> <b>class</b> SuperCoolGuitarWithFlames <b>extends</b> Guitar {
 
<b>private</b> String flameColor;
 
<font><i>//constructor, getters + setters</i></font><font>
}
</font>

通過擴充套件 Guitar 類，我們可以確保我們現有的應用程式不會受到影響。

3. Liskov替代

這可能是5個原則中最複雜的。簡單地說，如果A類是B類的子型別，那麼我們應該能夠用 A 替換 B 而不破壞我們程式的行為。讓我們直接跳轉到程式碼，以幫助我們圍繞這個概念：

<b>public</b> <b>interface</b> Car {
 
<b>void</b> turnOnEngine();
<b>void</b> accelerate();
}

在上面，我們定義了一個簡單的 Car 介面，其中包含了所有汽車應該能夠實現的幾種方法 - 開啟引擎並加速前進。

讓我們實現我們的介面併為方法提供一些程式碼：

<b>public</b> <b>class</b> MotorCar implements Car {
 
<b>private</b> Engine engine;
 
<font><i>//Constructors, getters + setters</i></font><font>
 
<b>public</b> <b>void</b> turnOnEngine() {
</font><font><i>//turn on the engine!</i></font><font>
engine.on();
}
 
<b>public</b> <b>void</b> accelerate() {
</font><font><i>//move forward!</i></font><font>
engine.powerOn(1000);
}
}
</font>

正如我們的程式碼描述的那樣，我們有一個可以開啟的引擎，我們可以增加功率。但等一下，2019年，埃隆馬斯克一直是一個忙碌的人。

我們現在生活在電動汽車時代：

<b>public</b> <b>class</b> ElectricCar implements Car {
 
<b>public</b> <b>void</b> turnOnEngine() {
<b>throw</b> <b>new</b> AssertionError(<font>"I don't have an engine!"</font><font>);
}
 
<b>public</b> <b>void</b> accelerate() {
</font><font><i>//this acceleration is crazy!</i></font><font>
}
}
</font>

將沒有引擎的電車放進一個混合物物件中，就改變了我們程式的行為。這是對Liskov替換的公然違反，並且比我們之前的2條原則更難修復。

一種可能的解決方案是將我們的模型重新設計為考慮到無引擎狀態的汽車的介面。

4.介面隔離

SOLID中的“I”代表介面隔離，它只是意味著更大的介面應該分成更小的介面。通過這樣做，我們可以確保實現類只需要關注它們感興趣的方法。

對於這個例子，我們將嘗試作為動物園管理員。更具體地說，我們將在熊圈中工作。

讓我們從一個介面開始，概述我們作為熊守護者的角色：

<b>public</b> <b>interface</b> BearKeeper {
<b>void</b> washTheBear();
<b>void</b> feedTheBear();
<b>void</b> petTheBear();
}

作為狂熱的動物園管理員，我們非常樂意為我們心愛的熊洗淨和餵食。然而，我們都非常清楚撫摸它們的危險。不幸的是，我們的介面相當大，我們別無選擇，只能實施程式碼來承擔責任。

讓我們通過將我們的大型介面分成3個獨立的介面來解決這個問題：

<b>public</b> <b>interface</b> BearCleaner {
<b>void</b> washTheBear();
}
 
<b>public</b> <b>interface</b> BearFeeder {
<b>void</b> feedTheBear();
}
 
<b>public</b> <b>interface</b> BearPetter {
<b>void</b> petTheBear();
}

現在，由於介面隔離，我們可以自由地只實現對我們重要的方法：

<b>public</b> <b>class</b> BearCarer implements BearCleaner, BearFeeder {
 
<b>public</b> <b>void</b> washTheBear() {
<font><i>//I think we missed a spot...</i></font><font>
}
 
<b>public</b> <b>void</b> feedTheBear() {
</font><font><i>//Tuna Tuesdays...</i></font><font>
}
}
</font>

最後，我們可以把危險的東西留給瘋狂的人：

<b>public</b> <b>class</b> CrazyPerson implements BearPetter {
 
<b>public</b> <b>void</b> petTheBear() {
<font><i>//Good luck with that!</i></font><font>
}
}
</font>

更進一步，我們甚至可以將我們的BookPrinter 類從之前的示例拆分為以相同的方式使用介面隔離。通過使用單個列印方法實現 Printer介面，我們可以例項化單獨的 ConsoleBookPrinter 和 OtherMediaBookPrinter 類。

5.依賴注入

當有人提到“依賴注入”這個詞時，可能會想到一些框架 - 谷歌的Guice，或者也許是Spring。但事實是，我們不需要複雜的框架來理解這個原則。

依賴注入只是在建立時注入類的依賴關係的技術，避免了危險的新關鍵字。

為了證明這一點，讓我們使用程式碼實現Windows 98計算機：

<b>public</b> <b>class</b> Windows98Machine {}

但沒有顯示器和鍵盤的電腦有什麼用？讓我們在建構函式中新增其中一個，以便我們例項化的每個 Windows98Computer 都預裝了一個Monitor 和一個鍵盤：

<b>public</b> <b>class</b> Windows98Machine {
 
<b>private</b> <b>final</b> Keyboard keyboard;
<b>private</b> <b>final</b> Monitor monitor;
 
<b>public</b> Windows98Machine() {
monitor = <b>new</b> Monitor();
keyboard = <b>new</b> Keyboard();
}
 
}

這段程式碼可以使用，我們將能夠在Windows98Computer 類中自由使用鍵盤和監視器。問題解決了？不完全的。通過使用 new 關鍵字宣告 Keyboard 和 Monitor ，我們將這3個類緊密耦合在一起。

這不僅使我們的 Windows98Computer 難以測試，而且我們也失去了在需要時用子類切換我們的Keyboard 類的能力。我們也耦合使用了我們的Monitor類。

讓我們看看當我們應用一些簡單的依賴注入時，同一個例子是如何看的：

<b>public</b> <b>class</b> Windows98Machine{
 
<b>private</b> <b>final</b> Keyboard keyboard;
<b>private</b> <b>final</b> Monitor monitor;
 
<b>public</b> Windows98Machine(Keyboard keyboard, Monitor monitor) {
<b>this</b>.keyboard = keyboard;
<b>this</b>.monitor = monitor;
}
}

優秀！我們已經解耦了依賴關係，並可以使用我們選擇的任何測試框架自由測試我們的 Windows98Machine 。(banq注：可以使用builder模式實現兩個輸入引數的注入)

結論

在本教程中，我們深入探討了面向物件設計的SOLID原則。

我們從一小段SOLID歷史開始，以及這些原則存在的原因。

我們逐字逐字地用一個違反它的快速程式碼示例來分解每個原則的含義。然後，我們瞭解瞭如何修復程式碼並使其符合SOLID原則。

程式碼在GitHub 上可用。

SOLID原則的堅實指南| Baeldung

您可能也會喜歡…