但你可能不知道OOD(Object-Oriented Design)還有五大基本原則，被Bob大叔稱為SOLID原則，字母為每個原則的首字母，遵循這些原則能夠讓你的代碼在擴展性、維護性以及重用性提高。而這些不正是我們所追求的嗎？
接下來，我們就一塊學習學習這些原則（內容較多，建議先收藏后反復觀看，文章末尾有很多參考鏈接）。
SRP(The Single Responsibility Principle)單一職責原則。
SRP是SOLID五大設計原則中最容易被誤解的一個，SRP不就是每個模塊都應該只做一件事嗎？非也非也，這只是在實現底層細節的實際原則，并非是SRP的全部。
SRP最初是這樣描述的：
任何一個模塊都應該有且只有一個被修改的原因(There should never be more than one reason for a class to change)
SRP的定義幾經迭代，最終被Robert C.Martin在《Clean Architecture》中定義為：
任何一個
軟件模塊都應該只對某一類行為者負責
那么上文中提到的軟件模塊究竟是指什么呢？大部分情況下，其最簡單的定義就是指一個源代碼文件。然而有些編程語言和編程環境并不是用源代碼文件來存儲程序的。在這些情況下，軟件模塊指的就是一組緊密相關的函數和數據結構。
來看一個正面例子，C標準庫中的
再來看一個反面例子，還記得剛開始學習單片機編程的時候，項目工程中從始至終就一個main源文件，真的是連頭文件都不寫的，一個main里面包含了LED、按鍵等相關全部代碼，這明顯是不符合SRP這一原則的。就像下圖一樣。
OCP(The Open-Closed Principle)開放封閉原則。
OCP的定義如下：
軟件實體應當對擴展開放，對修改關閉（Software entities should be open for extension，but closed for modification）
設計良好的計算機軟件應該易于擴展，同時抗拒修改。換句話說，一個良好的計算機系統應該在不需要修改的前提下就可以輕易被擴展。
OCP是系統框架設計的主導原則，其主要目的是讓系統易于擴展，同時限制其每次被修改所影響的范圍。實現的方式是通過將系統劃分為一系列的組件，并且將這些組件的依賴關系按層次結構進行組織，使得高階的組件不會因低階組件被修改而受到影響。
我們來看一個網絡中協議的例子，如下圖：
層級，最上方層級最高，每個層級有若干組件，高層級的組件依賴低層級的組件。LSP(LSP-Liskov Substitution Principle)里氏替換原則。
LSP定義：
使用基類對象指針或引用的函數必須能夠在不了解衍生類的條件下使用衍生類的對象(Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it)
里氏代換原則中說，任何基類可以出現的地方，子類一定可以出現。只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。
我們來看一個經典的反面案例，正方形(Square)與長方形(Rectangle)。
那這里提出疑問了，正方形和長方形之間的繼承關系是如何呢？
如果A is-a B，則認為B是基類，A為子類，A應該繼承B。那這個簡單了，眾所周知正方形是長方形，立即推，長方形是基類，正方形是子類，正方形應該繼承長方形。
基類長方形中有SetHeight()和SetWidth()方法，但是子類正方形有一個特點，長和寬是相等的，所以在實現SetHeight()和SetWidth()都必須同時設置寬和高，我們來看代碼。
還是那句話任何基類可以出現的地方，子類一定可以出現，所以在創建Rectangle對象指針的時候，這里其實給的是子類的對象，最終代碼運行斷言報錯。
Assertion?failed:?rect->GetArea()?==?10,?file?.\main.cpp,?line?10
如果new出來的對象是Rectangle，則程序能夠正常執行。如果new出來的是Square則會進入斷言。從而Square不能代替Rectangle，所以不符合LSP原則，實際上Square并不是Rectangle的子類。
正方形是長方形，但是他們的行為并不一樣，所謂的行為，就是抽象出來的東西。正方形只要有一個設置邊長的方法就行了，而長方形需要設置寬和高兩種方法。
ISP(ISP-Interface Segregation Principle)接口隔離原則。
ISP定義：
不應強制客戶端依賴于它們不使用的接口(Clients should not be forced to depend upon interfaces that they do not use.)
該原則還有另外一個定義：一個類對另一個類的依賴應該建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）
假如現在有一個OPS類。用戶1只需要使用OPS類的op1方法，用戶2只需要OPS類的op2方法，但是呢，OPS類除了提供op1和op2方法還提供了若干方法。如下圖：
此時用戶2沒什么意見，心想著反正能實現我要的功能就可以了。
但是呢，用戶1不愿意，于是就去找開發人員理論，我就要實現一個op1功能，給我整這么多依賴干啥。除了這個功能，其他的全部都給我隱藏掉，下班之前我就要，說完頭一扭就走了。
開發人員心想，這么簡單的事情，讓我下班之前給你，這不是
眼看人低嗎，說完就在用戶1和OPS之間又封裝一層IU1Ops接口，兩分鐘搞定。于是就去跟用戶1說，你用IU1Ops，里面有你要的接口，拿去用吧。說完頭一扭就走了。模型如下圖：
接口隔離原則和單一職責都是為了提高類的內聚性、降低它們之間的耦合性，體現了封裝的思想，但兩者是不同的：
DIP(DIP-Dependency Inversion Principle)依賴倒置原則。
DIP定義：
高層次的模塊不應該依賴低層次的模塊，他們都應該依賴于抽象(High level modules should not depend upon low level modules. Both should depend upon abstractions)
抽象不應該依賴于具體實現，具體實現應該依賴于抽象(Abstractions should not depend upon details. Details should depend upon abstractions)
這個名字看著有點別扭，“依賴”還“倒置”，這到底是啥意思？
依賴指兩個相對獨立的對象，當一個對象負責構造另一個對象的實例，或者依賴另一個對象的服務時，這兩個對象之間主要體現為依賴關系。
老樣子，看示例，現在甲方需要能讓BMW車跑起來的功能，再看一下乙方的設計。
司機有駕駛BMW車輛的方法，BMW車輛有run的方法，所以是甲方滿足需求的。
后來甲方需求變了，甲方不僅要能開BMW車，也要能開Benz車，卻發現使用乙方原來的的設計Benz車卻開不起來，因為+driver()只接受BMW的車輛，不接受Benz的車輛，這明顯不合理，一個司機會開BMW卻不會開Benz，太反常了。于是去找乙方重新設計。
乙方也認識到了不足，經過多方討論終于有了如下設計。
對于每種車輛，都應該有一個run的方法，所有的車輛都應該繼承ICar實現。而司機呢，也不應該依賴具體的車輛，而應該依賴所有車輛的抽象方法。原本直接指向BMW的依賴箭頭被反置了。現在即使甲方在添加別的車輛，司機仍然能開。不會出現只會開BMW而不會開其他車輛的情況了。
簡單來說，依賴倒轉原則就是指：代碼要依賴于抽象的類，而不要依賴于具體的類；要針對接口或抽象類編程，而不是針對具體類編程。根據上面的例子可以加深理解。
依賴倒置原則（Dependency Inversion Principle）是很多面向對象技術的根基。它特別適合應用于構建可復用的軟件框架，并且，因為抽象和細節已經彼此隔離，代碼也變得更易維護。
采用依賴倒置原則可以減少類間的耦合性，提高系統的穩定性，減少并行開發引起的風險，提高代碼的可讀性和可維護性。
https://zhuanlan.zhihu.com/p/280765580
END
來源：typedef
