單一職責原則

對于一個類而言，有且僅有一個引起他變化的原因或者說，一個類只負責一個職責

如果一個類承擔的職責過多，那么這些職責放在一起耦合度太高了，一個職責的變化可能會影響這個類其他職責的能力。

所以我們在做軟件設計的時候，要發現職責，并且把這些職責互相分開

例子1

對于看書這件事情，用手機看書和直接看紙質書相比，肯定紙質書的效率要高一些。

因為手機的職責太多了，接打電話、聽歌、看電視劇等等，我們在看書的時候，可能收別的職責的影響。

而紙質書，只有一個職責，沉浸式讀書。

例子2

電腦機箱中，由CPU、內存、硬盤、顯卡、主板等等。

假設我們的CPU、內存、應該、顯卡是高層模塊，電腦中應該叫易插拔，都插到主板中。

對于電腦這個主體而言，就符合單一職責原則，內存條壞了，不會影響CPU、磁盤和主板。

開閉原則

對擴展開發，對修改封閉【多擴展、少修改】

當我們面對新需求的時候，對程序的修改只是通過增加代碼的方式，而不用去修改已有的代碼。

這樣做我們程序變得更加，可擴展、可維護、可服用、靈活性。

例子

假設現在我們由兩個模塊，一個是高層模塊（做業務邏輯模塊），一個底層模塊（數據庫模塊）。

數據庫的一些常見操作比如：增刪改查，但是我們使用的數據庫可以是MySQL、SQLServer、Postgresql等等。

那么如果做到開閉原則吶，抽象出一個類，如果新加了數據庫去繼承這個類，然后自己去實現增刪改查接口。

這樣就做到了對擴展開發，對修改封閉了。

依賴倒置原則

高層模塊不應該依賴于底層模塊，他們都應該依賴于抽象

我們要針對接口編程，而不是針對實現編程

例子1

電腦舉例，CPU、內存、硬盤、顯卡都應該依賴于抽象接口，而不是依賴于具體的主板。

如果依賴于具體的主板，那么主板壞了，這些高層的設備都用不了了，這樣設計顯然不合理。

例子2

還是上面那個例子，高層模塊（業務邏輯層）和底層模塊（數據庫層）都不應該互相依賴，而是依賴于抽象。

高層模塊 => 抽象 => 低層模塊

抽象其實就是基類，底層模塊是子類。

MySQL、SQLServer、PostgreSQL都有增刪改查操作，假設有一天要用到別的數據庫

只需要再創建一個類，繼承抽象去實現這些接口，對于高層模塊而言，不需要任何的改變（或者只需要改變new的對象而已）

里氏替換原則

子類必須能夠替代父類

例子

假設鳥是父類，那么鴕鳥和企鵝能繼承于鳥類嗎？

如果按照初中老師講的，鴕鳥和企鵝雖然不能飛，但是屬于鳥類。

但是再我們編程的世界里面，如果鴕鳥和企鵝可以繼承鳥類，這是不合理的，違反了里氏替換原則。

還是舉一個例子，他們的高層模塊 => 抽象 => 低層模塊

如果抽象中要使用的方法就是鳥的會飛的方法，但是我們底層模塊是鴕鳥，根本不會飛，這樣就會產生嚴重的錯誤

所以里氏替換原子是實現依賴倒置原則的基礎