前面兩部分分別講述了簡單工廠模式和策略模式，後面還舉了例子進行簡單實現，這裡，讓我們瞭解下軟體設計的初衷，整合書上分為3章書寫的內容，這裡我們統一介紹我們寫程式碼應該注意的基本原則：

分別是

a、單一職責原則：就一個類而言，應該僅有一個引起它變化的原因。

如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者限制這個類完成其他職責的能力，當變化發生時，實際會遭到意想不到破壞；

當然，軟體實際真正要許多內容，就是發現職責並把哪些職責相互分離，其實要去判斷是否應該分離出類來，這也簡單，就是如果你能想到多餘一個的動機去改變一個類，那麼這個列就具有多於一個的職責。

b、開放-封閉原則：軟體實體類（模組、函式等單獨個體）應該可以擴充套件，但是不可以修改

也就是說一個類對於擴充套件是開放的，對於修改是封閉的。舉個簡單的例子就是說，如果一個專案需要新增新的功能，不過這個新的功能與一個老的功能相關，我們需要做的不是去修改老的類，增加一個分支判斷，何時執行新功能，何時執行老功能，而是新建一個類，繼承或實現老公能的類，從而實現新功能而不去修改老功能的類，這樣可以必變對原來的功能造成影響。

其實在這裡我們就可以重構專案了，因為無論模組是多麼的‘封閉’，都會存在一些無法對已封閉的變化，既然不可能完全封閉看，世紀人員必須對於他設計的模組應該對那種變化封閉做出選擇，他必須先猜測出最有可能發生的變化種類，然後構造抽象來隔離那些變化。當然，僅憑猜測肯定會有疏漏，我們希望在需求開始就知道後續的一系列變化，但我們也知道這是不可能的，所以，我們只能假設沒有變化，當需求到來的時候重構程式碼架構，音節變化。

開放-封閉原則是面向物件設計的核心所在，遵循這個原則可以帶來面向物件技術所說的巨大好處，也就是可維護，可擴充套件，可複用，靈活性好，開發人員應該僅對程式中呈現出頻繁變化的那些部分做出抽象，然而，對於應用程式中的每個部分都可以進行抽象同樣不是一個好主意，拒絕不成熟的抽象和抽象本身一樣重要。

c、里氏代換原則：子型別必須能替換他的父型別

就是一個原件實體如果能用一個父類的話，那麼一定適用於其子類，而它察覺不出父類物件和子類物件的區別，也就是說，在軟體裡，吧父類都替換成其子類，程式的行為沒有變化。只有當子類可以替換掉父類，軟體單位的功能不受影響時，父類才能真正被複用，而子類需在父類的基礎上增加新的行為。

d、依賴倒轉原則：說白了就是針對介面變成，不要針對實現程式設計，即 

    1、高層模組不應該依賴低層模組，兩個都應該依賴抽象

    2、抽象不應該依賴細節，細節應該依賴抽象

具體舉個例子，就是說不同專案之間，不同的人配合工作的時候，互相之間需要提供一個API文件，寫明對方想調這個介面需要傳入什麼引數，可以獲得什麼結果，但是具體的方法內部是如何實現的，呼叫方不需要考慮，但是編寫API介面的人需要注意的是，雖然你內部如何實現別人不理會，但你內部的變化不能影響API介面的呼叫。