針對筆者本人,在設計系統時,老是會忘記這些原則,因此特意整理資料編程
「原則」,英文譯爲:Principle,而對於原則一詞的解釋:原則是可以在類似場景下反覆運用的一套概念,有別於具體問題的狹義回答,即智者見智,對原則理解越透徹,則越能明白原則對你的影響有多大,而在軟件領域,特別是面向對象的領域裏,面向對象的設計原則更是基礎中的基礎,而這些原則的出現即是許多人的得出來的總結,架構
面向對象設計的設計原則不是必需要遵照的,而做爲一個優秀的軟件,想必都會有遵循這些原則,我特意指出這些原則不是必須的,可是,而說到原則,SOLID(單一功能、開閉原則、里氏替換、接口隔離以及依賴反轉)所包含的原則是經過引起編程者進行軟件源代碼的代碼重構進行軟件的代碼異味清掃,從而使得軟件清晰可讀以及可擴展時能夠應用的指南,因此我認爲原則應該在軟件的設計中不斷地使用,而成爲一種條件反射。函數
從圖中看到每一個原則的說明都是比較簡單的,但原則是經過實踐才能體會出它的重要性設計
SOLID(單一功能、開閉原則、里氏替換、接口隔離以及依賴反轉)是由羅伯特·C·馬丁在21世紀早期 引入的記憶術首字母縮略字3d
每一個類應該都有單一的功能(職責),並且由類徹底封裝起來,即解耦,注意功能並不表明這個類只有一個方法或者函數,保持一個類專一於單一功能點上的一個重要的緣由是,它會使得類更加的健壯,而在面向對象原則上的引伸,將職責定義爲引發變化的緣由,以提升內聚性來減小引發變化的緣由。職責過多,可能引發它變化的緣由就越多,這將致使職責依賴,相互之間就產生影響,從而大大損傷其內聚性和耦合度。對象
SRP爲最簡單的原則,也是最難運用好的原則blog
當已有的軟件須要增長一個新的功能時,不須要在已有的抽象層中進行修改,只須要擴展已有的實現層,核心思想即是面向抽象編程,在面向對象的編程中,抽象層和接口規定了類的的特徵,做爲一個抽象層,而後進行修改封閉,而繼承了抽象層的具體類實現了改變系統的行爲,從而知足擴展繼承
里氏替換原則即繼承機制的基礎,在任何父類出現的地方均可以用他的子類來替代,子類必須徹底覆蓋父類的方法,此原則反過來則是不成立的,子類能夠替換基類,可是基類不必定能替換子類,子類的全部方法必須在父類中聲明,或子類必須實現父類中聲明的全部方法接口
提供儘量小的單獨接口,而不要提供大的總接口,在面向對象設計中,接口(interface)提供了便於代碼在概念上解釋的抽象層,並創建了避免依賴的一個屏障。ip
分離接口的兩種實現方法:
1.使用委託分離接口。(Separation through Delegation)
2.使用多重繼承分離接口。(Separation through Multiple Inheritance)
該原則規定:
採用依賴倒置原則能夠減小類間的耦合性,當兩個模塊之間存在緊密的耦合關係時,最好的方法就是分離接口和實現:在依賴之間定義一個抽象的接口使得高層模塊調用接口,而底層模塊實現接口的定義,以此來有效控制耦合關係,達到依賴於抽象的設計目標,咱們先了解傳統的應用架構中,低層次的組件設計用於被高層次的組件使用。在這種結構下,高層次的組件直接依賴於低層次的組件去實現一些任務。這種對於低層次組件的依賴限制了高層次組件被重用的可行性。
依賴倒置原則就是要求調用者和被調用者都依賴抽象,這樣二者沒有直接的關聯和接觸,在變更的時候,一方的變更不會影響另外一方的變更。
參考的文章,維基:面向對象的設計原則