Make it simpler

已經有很多人寫過類似的文章了，不過我還是想記錄下來，最近對設計原則的理解，哪天回頭觀看，也有點印象：

單一職責原則：

      就一個類而言、應該僅有一個引起它變化的原因。 這句話的意思是說，如果有多種不同類型的需求改變了，都需要對該類進行改變，那么這個類就違背了單一職責原則，這個度非常難把握，個人感覺很多時候，單一職責原則比較滯后，大部分情況下都是在需求變更的時候，才發現這個某些類單一職責原則沒有太好落實，因此才去做的重構，其實發生這個情況的原因，個人感覺主要是在做設計的時候，還是功夫做得太少，如果能在紙上多畫畫，應該效果會更好。

      軟件設計真正要做的許多內容，就是發現職責并把那些職責相互分離----如果你能夠想到多于一個的動機去改變一個類，那么這個類就具有多于一個的職責。

開放-關閉原則 ：

      對于擴展是開放的，對于更改是封閉的。

      怎樣的設計才能面對需求的改變卻可以保持相對穩定，從而使得系統可以在第一個版本以后不斷推出新的版本呢？

      無論模塊是多么的‘封閉’，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對于他設計的模塊應該對哪種變化封閉做出選擇。他必須先猜測出最有可能發生的變化種類，然后構造抽象來隔離那些變化。

      在我們最初編寫代碼時，假設變化不會發生。當變化發生時，我們就創造抽象來隔離里后發生的同類變化。

      面對需求，對程序的改動是通過增加新代碼進行的，而不是更改現有的代碼。這就是開放-關閉原則的精神所在。 我們希望的是在開發工作展開不就就知道可能發生的變化。查明可能發生的變化所等待的時間越長，要創建正確的抽象就越困難。

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

依賴倒轉原則

      針對接口編程，而不要對實現編程：

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

            B. 抽象不應該依賴細節，細節應該依賴抽象。

      以上都是根據書上所寫，但個人在這里有些需要說明的，依賴倒轉原則與前面所講的原則都是一樣，不要將所有的地方，都寫成是對接口編程，那樣相當于是過度抽象，其實對整個軟件設計并沒有任何好處。一句話概括：只有當需要的時候，再進行抽象，這也是敏捷所描述的精神。

里氏代換原則

      一個軟件實體如果使用的是一個父類的話，那么一定適用于其子類，而且它察覺不出父類對象和子類對象的區別。也就是說，在軟件里面，把父類都替換成它的子類，程序的行為沒有變化。簡單地說，子類型必須能夠替換掉它們的父類型。

      只有當子類可以替換掉父類，軟件單位的功能不受到影響時，父類才能真正被復用，而子類也能夠在父類的基礎上增加新的行為。