單一職責原則
對于一個類而言，有且僅有一個引起他變化的原因或者說，一個類只負責一個職責
如果一個類承擔的職責過多，那么這些職責放在一起耦合度太高了，一個職責的變化可能會影響這個類其他職責的能力。
所以我們在做軟件設計的時候，要發現職責，并且把這些職責互相分開
例子1
對于看書這件事情，用手機看書和直接看紙質書相比，肯定紙質書的效率要高一些。
因為手機的職責太多了，接打電話、聽歌、看電視劇等等，我們在看書的時候，可能收別的職責的影響。
而紙質書，只有一個職責，沉浸式讀書。
例子2
電腦機箱中，由CPU、內存、硬盤、顯卡、主板等等。
假設我們的CPU、內存、應該、顯卡是高層模塊，電腦中應該叫易插拔，都插到主板中。
對于電腦這個主體而言，就符合單一職責原則，內存條壞了，不會影響CPU、磁盤和主板。
開閉原則
對擴展開發，對修改封閉【多擴展、少修改】
當我們面對新需求的時候，對程序的修改只是通過增加代碼的方式，而不用去修改已有的代碼。
這樣做我們程序變得更加，可擴展、可維護、可服用、靈活性。
例子
假設現在我們由兩個模塊，一個是高層模塊（做業務邏輯模塊），一個底層模塊（數據庫模塊）。
數據庫的一些常見操作比如：增刪改查，但是我們使用的數據庫可以是MySQL、SQLServer、Postgresql等等。
那么如果做到開閉原則吶，抽象出一個類，如果新加了數據庫去繼承這個類，然后自己去實現增刪改查接口。
這樣就做到了對擴展開發，對修改封閉了。
依賴倒置原則
高層模塊不應該依賴于底層模塊，他們都應該依賴于抽象
我們要針對接口編程，而不是針對實現編程
例子1
電腦舉例，CPU、內存、硬盤、顯卡都應該依賴于抽象接口，而不是依賴于具體的主板。
如果依賴于具體的主板，那么主板壞了，這些高層的設備都用不了了，這樣設計顯然不合理。
例子2
還是上面那個例子，高層模塊（業務邏輯層）和底層模塊（數據庫層）都不應該互相依賴，而是依賴于抽象。
高層模塊 => 抽象 => 低層模塊
抽象其實就是基類，底層模塊是子類。
MySQL、SQLServer、PostgreSQL都有增刪改查操作，假設有一天要用到別的數據庫
只需要再創建一個類，繼承抽象去實現這些接口，對于高層模塊而言，不需要任何的改變（或者只需要改變new的對象而已）
里氏替換原則
子類必須能夠替代父類
例子
假設鳥是父類，那么鴕鳥和企鵝能繼承于鳥類嗎？
如果按照初中老師講的，鴕鳥和企鵝雖然不能飛，但是屬于鳥類。
但是再我們編程的世界里面，如果鴕鳥和企鵝可以繼承鳥類，這是不合理的，違反了里氏替換原則。
還是舉一個例子，他們的高層模塊 => 抽象 => 低層模塊
如果抽象中要使用的方法就是鳥的會飛的方法，但是我們底層模塊是鴕鳥，根本不會飛，這樣就會產生嚴重的錯誤
所以里氏替換原子是實現依賴倒置原則的基礎
