設計模式基本原則

　　前段時間，聆聽一大牛的教誨：「c語言、java語言、C#語言這些都是一些基本的工具，而它們其中的語法、技能都是一些很簡單的基礎知識，剛接觸編碼時確定會有不少的知識、技能你不懂，但你只要碰到而且學習確定可以熟練使用。因此語言、技能都不重要，重要的是脫離語言工具的思想，編程的思想。設計模式是思想的體現，多多學習確定沒錯」。大牛的教誨讓小弟收益匪淺，這不開始學習設計模式了。

　　學習設計模式以前，首先明確模式是針對面向對象的，它的三大特性，封裝、繼承、多態。面向對象設計模式有5大基本原則：單一職責原則、開發封閉原則、依賴倒置原則、接口隔離原則、Liskov替換原則。咱們學習的設計模式都是在面向對象的特性以及5大基本原則的基礎上衍生而來的具體實現，因此學習以前有必要介紹幾大原則的基本概念。

 

單一職責原則（SRP）：就一個類而言，應該僅有一個引發它變化的緣由。

若是一個類承擔的職責過多，就等於把這些職責耦合在一塊兒，一個職責的變化可能會削弱或者抑制這個類完成其餘職責的能力。這種耦合會致使脆弱的設計，當變化發生時，設計會遭受到意想不到的破壞。

單一職責原則能夠看作是低耦合、高內聚在面向對象原則上的引伸，將職責定義爲引發變化的緣由，以提升內聚性來減小引發變化的緣由。職責過多，可能引發它變化的緣由就越多，這樣致使職責依賴，相互之間就會產生緣由，大大損傷其內聚性和耦合度。

 

開放封閉原則：對擴展時開放的，對修改是封閉的。

開放封閉原則是面向對象設計的核心所在。遵循這個原則能夠帶來面向對象技術所聲稱的巨大好處：可維護、可擴展、可複用、靈活性好。開發人員應該僅對程序中呈現頻繁變化的那些部分作出抽象，然而，對於應用程序中的每一個部分都刻意地進行抽象一樣也不是一個好主意。拒毫不成熟的抽象和抽象自己同樣重要。「需求老是變化」沒有不變的軟件，因此須要用開放封閉原則來封閉變化知足需求，同時還能保持軟件內部的封裝體系穩定，不被需求的變化影響。

 

依賴倒置原則：

1 高層模塊不該該依賴低層模塊。兩個都應該依賴抽象。

2 抽象不該該依賴具體（細節）。具體（細節）應該依賴抽象。

依賴倒置其實能夠說是面向對象設計的標誌，用哪一種語言來編寫程序不重要，若是編寫時考慮的都是如何針對抽象編程而不是針對細節編程，即程序中全部依賴關係都是終止於抽象類或者接口，那就是面向對象的設計，反之就是過程化的設計了。

 

接口隔離原則：

使用多個專門的接口比使用單一的總接口要好。

一個類對另一個類的依賴性應當是創建在最小的接口上的。

一個接口表明一個角色，不該當將不一樣的角色都交給一個接口。沒有關係的接口合併在一塊兒，造成一個臃腫的大接口，這是對角色和接口的污染。

「不該該強迫客戶依賴於它們不用的方法。接口屬於客戶，不屬於它所在的類層次結構。」這個說得很明白了，再通俗點說，不要強迫客戶使用它們不用的方法，若是強迫用戶使用它們不使用的方法，那麼這些客戶就會面臨因爲這些不使用的方法的改變所帶來的改變。

 

Liskov替換原則：

子類型必須可以替換掉它們的父類型。

任何基類能夠出現的地方，子類必定能夠出現。 LSP是繼承複用的基石，只有當衍生類能夠替換掉基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也可以在基類的基礎上增長新的行爲。里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。

 

面向對象最終的設計目標：

• 可擴展性：有了新的需求，新的性能能夠容易添加到系統中，不影響現有的性能，也不會帶來新的缺陷。
• 靈活性：添加新的功能代碼修改平穩地發生，而不會影響到其它部分。
• 可替換性：能夠將系統中的某些代碼替換爲相同接口的其它類，不會影響到系統。

 

基本設計原則介紹完畢，下一篇從簡單工廠模式寫起。