設計模式原則

解釋：對擴充套件開放，對修改關閉。

案例：書店打折

首先定義乙個book的介面，其中有getprice方法，獲取價錢。然後實現類novelbook實現book的介面。在上線一段時間之後，書店打算打折****。

這個時候我們的方案有如下三種：

給book介面增加乙個打折的方法，但是僅僅有一種書要打折，我們就要求全部種類的書都要實現打折方法，這個方案顯然是行不通的。

修改novelbook的getprice方法，但是我們也有需要獲取原價的需求，這個方案顯然也不是很友好

寫乙個offnovelbook的類繼承novelbook，增加getoffprice方法。這個方案可以讓我們在不修改原有系統的基礎上去實現變化。此方案可行。

解釋：乙個類中只有一種職責，引起類中發生變化的原因也只有一類

案例：手機

在沒有遵循單一職責的時候，我們這樣設計手機。

實現單一職責的時候我們是這樣設計手機的。

附加說明：這個原則是工程師下意識都會遵守的，並不會很難。難就難在需求的變更，導致了原本只有乙個職責的類變更為有兩個或以上的職責。這個時候是否需要遵守這個原則就得見仁見智了。

解釋：只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新

案例：矩形和長方形

定義乙個四邊形的介面，他有長和寬兩個屬性。矩形類實現四邊形介面，並且提供計算體積的方法。長方形都繼承矩形類，並且提供計算周長的方法。那麼只要是矩形出現的地方，我們都可以用長方形類來代替，並且不影響使用。

如果不遵守黎克特制替換原則：

那麼在長方形類繼承矩形類的時候，覆蓋掉計算面積的方法，那麼當子類代替父類的時候，方法會發生變化，這樣就不符合黎克特制替換原則了。

解釋：模組間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過介面或抽象類產生的

案例：司機與汽車

司機有乙個開車的方法，引數是賓士汽車類。這樣司機和賓士汽車就發生了耦合。如果那一天司機不想開賓士了，想開寶馬，新建了乙個寶馬類，但是司機並不能開寶馬，因為司機已經和賓士汽車發生了耦合。

根據依賴倒轉原則是這樣寫的**

汽車有乙個介面類，司機有乙個開車的方法，引數是汽車的介面類。這樣只要讓賓士和寶馬實現汽車的介面類，司機就可以開賓士和寶馬了。甚至五菱巨集光實現了汽車的介面類，司機還能成為秋名山的老司機。

解釋：介面中不應該存在子類用不到卻必須實現的方法

假設做**需要兩個步驟，第一步是前端程式設計，第二步是後端程式設計，那麼設計乙個介面，裡面有兩個方法，乙個是前端程式設計，乙個是後端程式設計。那麼全棧工程師可能就乙個人完成了**的設計。那如果是專注後端的程式設計師可能就不需要實現前端程式設計了。這就違背了介面隔離原則。

應該這麼設計：設計兩個介面，將前端程式設計和後端程式設計分離開。這就是介面隔離了。這樣就避免了讓後端程式設計師承擔不實現前端程式設計的風險了。

解釋：乙個軟體實體應當盡可能少的與其他實體發生相互作用。每乙個軟體單位對其他的單位都只有最少的知識，而且侷限於那些與本單位密切相關的軟體單位。

案例：

在沒有遵循迪公尺特原則的時候，我可能和很多人發生交流，因此我會去了解和適應不同的人，迪公尺特法則告訴我們，我們應該只和密切相關的人發生交流。如圖：