這幾章內容都是說的設計模式的原則，其實也就是面向對象的一些基本使用原則，一般任何一本書上都會寫，只是歸納總結的沒有這么好而已，可是這些原則用起來，可真不容易，這些原則都用會了，那么設計模式也就學通了（目標啊 ），理解和解釋都不難，就是用起來不簡單啊！！！ ### 單一職責原則 就一個類而言，應該僅有一個引起它變化的原因。（摘抄） 這個通俗的解釋應該把各個類都劃分清楚，功能都盡量的分開，不要界面和邏輯處理寫到一個類里面。 ### 開放——封閉原則 是說軟件實體（類，模塊，函數等等）應該可以擴展，但是不可以修改。（摘抄） 也就是說盡量的去寫接口，抽象類，如果需要增加功能，那么實現接口，繼承父類就好，而不需要去修改已經寫好的代碼，前面提到的兩種模式感覺就是單一原則和開放封閉原則的結合。 感覺書上的有一段話寫得很好，簡單來說就是應該對那些需要頻繁變化的部分進行抽象，而不是對每一個部分都去可以的抽象，這樣才能做到理解了面向對象。 拒絕不成熟的抽象和抽象本身一樣重要。（摘抄） 這時就要學會去判斷，那些部分是需要拓展的，而哪些部分是不需要拓展的，這就需要根據自己的實際情況來判斷，過于多的不成熟抽象，會造成代碼量的增加和結構的復雜，會讓別人感覺繞來繞去的。 ### 依賴倒轉原則 1.高層模塊不應該依賴低層模塊。兩個都應該依賴抽象。 2.抽象不應該依賴細節。細節應該依賴抽象。（摘抄） ### 里氏代換原則 子類型必須能夠替換掉它們的父類型。（摘抄） 后面兩種原則放在一起說吧，書上也是把這兩種放在一個章節的。這個我用一個簡單的例子說一下我的理解 例如你的程序，需要做兩種數據訪問操作，一種是從網絡獲取數據，一種是從本地獲取數據，那么這兩種方法的實現肯定是不同的，假如你這時候把寫成函數，那么就非常不好操作和修改，如果要加一個操作的話那么就是滅頂之災而且別的類無法調用這兩個操作，如果你把這兩種操作分別寫成兩個類那么比寫成兩個函數會好一點，但是這樣，要是類一多，那么就不方便了，所以這時就可以抽象一層，把獲取數據作為一層，然后使用者依賴于這個抽象類，實現者也依賴于這個抽象類，那么增加類，修改類，對使用者就沒有影響了，只要抽象類保持不變即可。 ### 總結 就用前面提到過的計算器的例子來解釋這四種原則把，把加減乘除分開，體現了單一原則，四個實現類繼承于抽象出來的父類，體現了依賴倒轉和開放——封閉原則，使用時，把子類向上轉型成父類對象，這時就用到了里氏代換原則。