SOLID 是面向對象設計5大重要原則的首字母縮寫，當我們設計類和模塊時，遵守 SOLID 原則可以讓軟體更加健壯和穩定。那麼，什麼是 SOLID 原則呢？本篇文章我將談談 SOLID 原則在軟體開發中的具體使用。 單一職責原則（SRP） 單一職責原則（SRP）表明一個類有且只有一個職責。一個類就像 ...
SOLID 是面向對象設計5大重要原則的首字母縮寫，當我們設計類和模塊時，遵守 SOLID 原則可以讓軟體更加健壯和穩定。那麼，什麼是 SOLID 原則呢？本篇文章我將談談 SOLID 原則在軟體開發中的具體使用。
單一職責原則（SRP）
單一職責原則（SRP）表明一個類有且只有一個職責。一個類就像容器一樣，它能添加任意數量的屬性、方法等。然而，如果你試圖讓一個類實現太多，很快這個類就會變得笨重。任意小的改變都將導致這個單一類的變化。當你改了這個類，你將需要重新測試一遍。如果你遵守 SRP，你的類將變得簡潔和靈活。每一個類將負責單一的問題、任務或者它關註的點，這種方式你只需要改變相應的類，只有這個類需要再次測試。SRP 核心是把整個問題分為小部分，並且每個小部分都將通過一個單獨的類負責。
假設你在構建一個應用程式，其中有個模塊是根據條件搜索顧客並以Excel形式導出。隨著業務的發展，搜索條件會不斷增加，導出數據的分類也會不斷增加。如果此時將搜索與數據導出功能放在同一個類中，勢必會變的笨重起來，即使是微小的改動，也可能影響其他功能。所以根據單一職責原則，一個類只有一個職責，故創建兩個單獨的類，分別處理搜索以及導出數據。
開放封閉原則（OCP）
開放封閉原則（OCP）指出，一個類應該對擴展開放，對修改關閉。這意味一旦你創建了一個類並且應用程式的其他部分開始使用它，你不應該修改它。為什麼呢？因為如果你改變它，很可能你的改變會引發系統的崩潰。如果你需要一些額外功能，你應該擴展這個類而不是修改它。使用這種方式，現有系統不會看到任何新變化的影響。同時，你只需要測試新創建的類。
假設你現在正在開發一個 Web 應用程式，包括一個線上納稅計算器。用戶可以訪問Web 頁面,指定他們的收入和費用的細節,並使用一些數學公式來計算應納稅額。考慮到這一點，你創建瞭如下類：
public class TaxCalculator
{
public decimal Calculate(decimal income, decimal deduction, string country)
{
decimal taxAmount = 0;
decimal taxableIncome = income - deduction;
switch (country)
{
case "India":
//Todo calculation
break;
case "USA":
//Todo calculation
break;
case "UK":
//Todocalculation
break;
}
return taxAmount;
}
}這個方法非常簡單，通過指定收入和支出，可以動態切換不同的國家計算不同的納稅額。但這裡隱含了一個問題，它只考慮了3個國家。當這個 Web 應用變得越來越流行時，越來越多的國家將被加進來，你不得不去修改 Calculate 方法。這違反了開放封閉原則，有可能你的修改會導致系統其他模塊的崩潰。
讓我們對這個功能進行重構，以符合對擴展是開放，對修改是封閉的。
根據類圖，可以看到通過繼承實現橫向的擴展，並且不會引發對其他不相關類的修改。這時 TaxCalculator 類中的 Calculate 方法會異常簡單：
public decimal Calculate(CountryTaxCalculator obj)
{
decimal taxAmount = 0;
taxAmount = obj.CalculateTaxAmount();
return taxAmount;
}里氏替換原則（LSP）
里氏替換原則指出，派生的子類應該是可替換基類的，也就是說任何基類可以出現的地方，子類一定可以出現。值得註意的是，當你通過繼承實現多態行為時，如果派生類沒有遵守LSP，可能會讓系統引發異常。所以請謹慎使用繼承，只有確定是“is-a”的關係時才使用繼承。
假設你在開發一個大的門戶網站，並提供很多定製的功能給終端用戶，根據用戶的級別，系統提供了不同級別的設定。考慮到這個需求，設計如下類圖：
可以看到，ISettings 介面有 GlobalSettings、SectionSettings 以及 UserSettings 三個不同的實現。GlobalSettings 設置會影響整個應用程式,例如標題、主題等。SectionSettings 適用於門戶的各個部分,如新聞、天氣、體育等設置。UserSettings 為特定登錄用戶設置,如電子郵件和通知偏好。
這樣的設計沒問題，但如果有另一個需求，系統需要支持游客訪問，唯一區別是游客不支持系統的設定，為了滿足這個需求，你可能會如下設計：
public class GuestSettings : ISettings
{
public void GetSettings()
{
//get settings from database
//include guest name、ip address...
}
public void SetSettings()
{
//guests are not allowed set settings
throw new NotImplementedException();
}
}這樣沒問題嗎？準確來說，系統存在隱患。當單獨使用 GuestSettings 時，因為我們瞭解游客不能設置，所以我們潛意識並不會主動調用 SetSettings 方法。但是由於多態，ISettings 介面的實現可以被替換為 GuestSettings 對象，當調用SetSettings 方法時，可能會引發系統異常。
重構這個功能，拆分為兩個不同的介面：IReadableSettings 和 IWritableSettings。子類根據需求實現所需的介面。
介面隔離原則（ISP）
介面隔離原則（ISP）表明類不應該被迫依賴他們不使用的方法，也就是說一個介面應該擁有儘可能少的行為，它是精簡的，也是單一的。
假設你正在開發一個電子商務的網站,需要有一個購物車和關聯訂單處理機制。你設計一個介面 IOrderProcessor,它用包含一個驗證信用卡是否有效的方法（ValidateCardInfo）以及收件人地址是否有效的方法（ValidateShippingAddress）。與此同時，創建一個OnlineOrderProcessor 的類表示線上支付。
這非常好，你的網站也能正常工作。現在讓我們來考慮另一種情形，假設線上信用卡支付不再有效，公司決定接受貨到付款支付。
乍一看,這個解決方案聽起來很簡單,你可以創建一個CashOnDeliveryProcessor 並實現 IOrderProcessor 介面。貨到付款的購買方式不會涉及任何信貸卡驗證,所以，CashOnDeliveryOrderProcessor 類內部的 ValidateCardInfo 方法拋出 NotImplementedException。
這樣的設計在未來可能會出現的潛在問題。假設由於某種原因線上信用用卡付款需要額外的驗證步驟。自然,IOrderProcessor 將被修改，它將包括那些額外的方法,於此同時 OnlineOrderProcessor 將實現這些額外的方法。然而,CashOnDeliveryOrderProcessor 儘管不需要任何的附加功能,但你必須實現這些附加的功能。顯然，這違反了介面隔離原則。
你需要將這個功能重構：
新的設計分成兩個介面。IOrderProcessor 介面只包含兩個方法：ValidateShippingAddress 和 ProcessOrder，而 ValidateCardInfo 抽象到到一個單獨的介面：IOnlineOrderProcessor。現在,線上信用卡支付的任何改變只局限於IOnlineOrderProcessor 和它的子類實現，而 CashOnDeliveryOrderProcessor 是不會被影響。因此,新設計符合介面隔離原則。
依賴倒置原則（DIP）
依賴倒置原則（DIP）表明高層模塊不應該依賴低層模塊，相反，他們應該依賴抽象類或者介面。這意味著你不應該在高層模塊中使用具體的低層模塊。因為這樣的話，高層模塊變得緊耦合低層模塊。如果明天，你改變了低層模塊，那麼高層模塊也會被修改。根據DIP原則，高層模塊應該依賴抽象（以抽象類或者介面的形式），低層模塊也是如此。通過面向介面（抽象類）編程，緊耦合被移除。
那麼什麼是高層模塊，什麼是低層模塊呢？通常情況下，我們會在一個類（高層模塊）的內部實例化它依賴的對象（低層模塊），這樣勢必造成兩者的緊耦合，任何依賴對象的改變都將引起類的改變。
依賴倒置原則表明高層模塊、低層模塊都依賴於抽象，舉個例子，你現在正在開發一個通知系統，當用戶改變密碼時，郵件通知用戶。
public class UserManager
{
public void ChangePassword(string username,string oldpwd,string newpwd)
{
EmailNotifier notifier = new EmailNotifier();
//add some logic and change password
//Notify the user
notifier.Notify("Password was changed on "+DateTime.Now);
}
}這樣的實現在功能上沒有問題，但試想一下，新的需求希望通過SNS形式通知用戶，那麼我們只能手動將EmaiNorifier 替換為 SNSNotifier。在這兒，UserManager 就是高層模塊，而EmailNotifier 就是低層模塊，他們彼此耦合。我們希望解耦，依賴於抽象 INotifier，也就是面向介面的編程。
小結
本篇博客為大家介紹了面向對象設計的 SOLID 原則，並以具體的案例輔助講解。你可以看到，繼承和多態在SOLID 原則中扮演了非常重要的角色。我們的應用程式不能過度設計，當然也不能隨意設計。瞭解基本的 SOLID 原則能讓你的應用程式變得健壯。你可以在Github 上查看具體的示例代碼：https://github.com/MEyes/SOLID.Principles
